上篇所说打性能优化点基本上都是针对silverlight本身相关的,其实silverlight作为一个精简的跨平台.net运行时,我们同样需要注意底层的一些性能问题,比如今天所要说的struct 与 class。

说道struct和class,这就要从CLR 的类型说起。

CLR类型

underlying type:基础类型,包括int,short,long,ushort等。

Reference Type:引用类型,其实java/.net程序中大多数类型都是引用类型。对于基本类型,

Value Type:从System.ValueType继承而来,直接在栈上创建。在C++中,我们可以随意在栈上创建和销毁对象,在java中干脆就只有基本类型才能这样做。而.NET中除了基本类型以外还给予我们另一种选择,就是struct。在栈上创建的对象的好处就是速度快销毁也快,不需要等待堆上的GC老人家。

Enum:枚举。其实CLR中的枚举也是Value Type,个人认为C#中的枚举特性如可以标识数值、进行位运算等比java的enum要强很多。

其他:其实还有很多特定的类型,比如Array,interface,pointer,ByRef,TypeRef等。这些类型属于上述的几大类的特定品种,不涉及本文我就不多说了。

struct与class需要注意的地方

好了,既然struct属于ValueType,那么就有这先天的优势---在栈上分配,栈上的对象有编译器自动创建和销毁,还有一点,对于数组其自身是引用类型,因此无论包含的是结构体还是类对象的引用,所有数组都通过堆分配内存。然而,一次性分配结构体数组的所有内存,使得使用结构体仍然有一些优点。结构体数组中的所有内存都是连续的,因此相比于堆中分散的内存,程序可以更加快速地访问结构体数组中的元素。总而言之在栈上创建对象/销毁对象的速度是非常快的,但是栈资源有限,不适合处理复杂的大的逻辑,所以结构体处理小对象,类处理复杂的打对象逻辑;类创建一个新对象,只是创建了一个引用,新对象的修改同时也会反映到源对象上,而结构体创建一个新对象后是创造源对象的一个副本,新对象的任何修改不会反应到源对象上,所以栈并非万金油,对于复杂生命周期的对象在栈上很难管理,而专由GC负责的堆则正好适用管理复杂对象的生命周期。

还有一点需要注意:值对象都是值传递,类对象都是引用传递,这就意味着值对象在传参、赋值过程中会消耗更多的内存,这也是我们需要合理使用struct的因素。

测试

下面我们来做个测试,看看struct和class在性能上的差异。

我们从三个方面考察:

1.对象创建速度

2.小对象值传递与引用传递速度对比

测试代码如下

static void vs1()
        {
            
int nLoop = 20000 * 20000;
            var sw 
= new Stopwatch();
            Console.WriteLine(
"对象创建速度对比...");
            sw.Start();
            
for (int i = 0; i < nLoop; i++)
            {
                var o 
= new A1();
                o.a 
= 10;
                o.b 
= 15;
                o.c 
= "b";
            }
            sw.Stop();
            Console.WriteLine(sw.Elapsed);
            sw.Restart();
            
for (int i = 0; i < nLoop; i++)
            {
                var o 
= new A2();
                o.a 
= 10;
                o.b 
= 15;
                o.c 
= "b";
            }
            sw.Stop();
            Console.WriteLine(sw.Elapsed);
        }

相关文章:

  • 2021-09-09
  • 2022-01-18
  • 2022-12-23
  • 2021-12-22
  • 2021-05-19
  • 2022-02-06
  • 2021-11-26
猜你喜欢
  • 2021-08-29
  • 2022-02-16
  • 2021-10-21
  • 2021-12-23
  • 2021-10-28
  • 2022-01-09
相关资源
相似解决方案