CYQ.Data 轻量数据层之路 MDataTable 绑定性能优化之章(十一)

  • 时间:
  • 浏览:1
  • 来源:大发5分快乐8_极速5分11选5

过多过多过多过多你这名 1个家伙了,里面那个家伙还行,下面那个家伙就大大的不行了,Type.GetType依据,一点人此人 拈着点用了。

简单的说过多过多过多过多自定义的MDataTable性能严重不足理想,比DataTable还差,那还自定义干哪些?直接使用DataTable不就了事了?

得出的结果是:

测试结果:

第一步,从实现绑定机制上走,首先自定义的MDataTable走的绑定机制源自DataReader依据,和DataTable不一样,于是产生第一1个想法:

http://www.cnblogs.com/cyq1162/archive/2010/09/01/1814901.html

4:这是测试结果了。

1:使用了框架:sql 100的分页存储过程[临时表分的页]:

既然抓到了真胸,那我那我的模仿所处的意义好像有的是的是那么明显了,以都能不能 优化这里,哪些模仿都能不能 上加了,一并又都能不能 恢复那我10倍的性能差距。

不过,还是要抓个问底,究竟是哪句代码影响了性能。

以下是说明:

于是把框架简单修改一下,开放了SQLHelper,开放返回DataTable的依据,接着产生了以下的测试代码:

测试结果:

导致 一:数据查询速率

1:MDataTable:312100

2:DataTable:17187100 

结论是:
那我比DataTable快10倍的差距,纯减到5倍多一点。

示例1测试结果:

3:他的框架测试结果:

1:     DataTable:101562100

2: SqlDataReader:8437100

结论是:
用SqlDataReader绑定比DataTable绑定更快。

接着增加依据,为属性设置值:手动敲哪些代码,一点人说累不累人。

于是,最后得出结论是:还果真我绑定代码写的有问题图片,导致 性能比DataTable差了一点

为单元价值形式上加多一1个属性,换掉整个CellValueType类。

测试结果:

按理就那么算了,绑定更快,实例化时过多再说那么快,也是都能不能 接受的。

1:MDataTable:179687100

2:DataTable: 10312100

结论:
自定义的MDataTable在绑定时比DataTable慢了0.7倍左右。

在构造头部价值形式时,完成对Type的初始设置,如下:

1:MDataTable:1562100

2:DataTable: 17187100 

结论:
10倍的差距速率回来了。

1:MDataTable:1871000

2: DataTable:26562100

结论:
直接回返自定义的MDataTable比DataTable 快0.N倍。

OK,至此,相关的返回取价值形式体的Type属性就行了,最后看测试结果:

昨天jyk进群后,用Microsoft Application Center Test 对CYQ.Data 框架进行进行了一下压力测试

示例3:

既然代码写的严重不足好,就得优化了。于是接着研究DataReader的绑定接口的实现,发现有那么一点返回代码:

接着在单元格类里增加该类,并在为单元格值赋值时调用此依据:

接着又用示例1:

1: MDataTable:89062100

2: DataTable:110937100

结论:
MDataTable在绑定时性能终于上去了,超越DataTable了

三:代码优化之章

新建了一1个类CellValueType:

对示例2测试结果:

于是继续研究,采取代码注释,步步换回那我的代码测试,终于把性能杀手抓出来了:

于是新生依据又产生了:

导致 二:绑定机制

测试结果:

1:MDataTable:1562100

2: DataTable:1562100

结论:
自定义的MDataTable比DataTable速率快10倍。

最后结案陈词:

从以上结果看出,无论在实例化,还是在查询速率上,自定义的MDataTable有的是优于DataTable的。那我结果在绑定时反而更快了,于是继续分析。

版权声明:本文原创发表于博客园,作者为路过秋天,原文链接:

改完就让,马上测试结果:

还记得我在发布:CYQ.Data 轻量数据层之路 自定义MDataTable绑定续章(七) 时,在最下面的留言中,有一1个测试

当然了,我当时的第一想法,MDataTable是不应该比DataTable慢的,算下体积,关联的类,都比DataTable复杂那么多,为啥么导致 比DataTable性能差呢?

当然了,一并我发现通过Value.GetType是有问题图片的,导致 绑定的值是Null,并有的是都能不能 判断了事,不过每次对Value取值过多过多过多过多太稳。

得出的结果是:

一并DataType增加一内部依据用于从SqlType转到Type:[又是手动敲的,累死人罗]

不过就在回头间,我就要要到了,速率慢的导致 导致 在并有的是现的绑定机制上。

用源生的SqlDataReader绑定和DataTable绑定比较,测试代码:

示例1:测试代码如下:

继续欢迎光大群众对本框架的使用与测试,本框架将与时俱进,尽情做到让使用者放心,省心。

欢迎留言讨论。

瞬间给了我一点启发,那过多过多过多过多模拟同类的实现依据了:

1:MDataTable:8710000

2:DataTable:110937100 

结论:
速率上仍超越了DataTable,并有的是没超过多少。不过比起就让慢了0.7倍左右到现在反超回来,是一大提升了。

并增加所有类型属性,一就让刚开始是prop的一1个一1个敲,累死人了。

2:把存储过程直接上加select的话:

一并也怀疑是有的是从SqlDataReader隐藏转换到MDataTable时,造成的性能差。

示例2:测试代码,看两句加红标注:

示例4:

一切就绪,于是回到MDataTable实现接口的实现之处,写下和DataReader同类的代码:

1、DataTable :714次/秒

2、MDataTable:559 次/秒 (简单存储过程)

3、MDataTable:100 次/秒 (完整篇 存储过程)

否则截了几张图上来,不到纯图如下:

并有的是得之绑定时比DataTable慢,但具体慢的导致 ,还是得找出来的。

于是,我在里面的测试代码中,从界面拖了一1个控件,分别为之绑定控件测试:

用的里面的示例2:

第一步测试一下:返回一1个MDataTable是有的是比返回一1个DataTable慢。