ADO.net，Linq to SQL和Entity Framework性能实测分析

ADO.net，Linq to SQL和Entity Framework性能实测分析

摘自:http://cid-79cf5e75e6e5fd50.spaces.live.com/blog/cns!79CF5E75E6E5FD50!379.entry

　　测试环境当然就是我这台笔 记本了，受限与硬盘转速，运行起来一定是不如台式机的，但至少保证了三个方案相同的软硬件环境：Windows Server 2008，Visual Studio 2008，MS SQL Server 2008，清一色的最新产品。

　　测试分成六个阶段，数据量分别为 10，10，100，1千，1万，10万逐级增长，分别测试了读取、写入、更改、删除四个基本的操作的耗时，结果如下（时间单位：秒）：

第一次读写10条数据
读写方式	读取耗时	添加耗时	修改耗时	删除耗时	平均耗时
当前机制(简化)	0.007	0.35	0.02	0.014	0.09775
LINQ to SQL	0.023	0.083	0.102	0.068	0.069
Entity Framework	0.238	3.084	0.009	0.006	0.83425

第二次读写10条数据
读写方式	读取耗时	添加耗时	修改耗时	删除耗时	平均耗时
当 前机制(简化)	0.002	0.034	0.011	0.020	0.01675
LINQ to SQL	0.003	0.011	0.043	0.058	0.02875
Entity Framework	0.004	0.006	0.005	0.004	0.00475

操作100条数据
读写方式	读取耗时	添加耗时	修改耗时	删除耗时	平均耗时
当 前机制(简化)	0.005	0.202	0.103	0.062	0.093
LINQ to SQL	0.003	0.083	0.350	0.298	0.1835
Entity Framework	0.004	0.035	0.030	0.021	0.0225

操作1000条数据
读写方式	读取耗时	添加耗时	修改耗时	删除耗时	平均耗时
当 前机制(简化)	0.044	2.086	1.056	0.720	0.9765
LINQ to SQL	0.006	0.805	3.035	2.925	1.69275
Entity Framework	0.010	0.392	0.296	0.209	0.22675

操作10000条数据
读写方式	读取耗时	添加耗时	修改耗时	删除耗时	平均耗时
当 前机制(简化)	0.435	21.069	10.328	6.925	9.68925
LINQ to SQL	0.02	7、973	29.985	28.891	16.71725
Entity Framework	0.029	4.142	3.321	2.434	2.47925

操作100000条数据
读写方式	读取耗时	添加耗时	修改耗时	删除耗时	平均耗时
当 前机制(简化)	4.525	213.603	100.668	82.203	100.25
LINQ to SQL	0.207	80.789	305.912	290.481	169.347
Entity Framework	0.387	42.402	38.497	24.36	26.4115

【测试总结】

　　第一阶段测试结果非常出人意料，ADO.net和LINQ to SQL操作数据的时间都控制在0.5秒以内，非常的迅速，但是Entity Framework在添加这步表现非常差，由于这五步是连续测试，其中添加数据是第一步操作，而EF在在进行第一步操作的时候足足延迟了3秒钟！这3秒钟 到底EF在做什么？

　　从第二阶段开始，性能的优劣就非常明显的展现在我们面前，第二阶段到第六阶段，不论操作数据量的大小，图中的耗时 比例几乎是相同的。Entity Framework无可争议的以极高的效率在三种方案中脱颖而出，而LINQ to SQL的龟速修改和删除操作消耗的时间几乎是EF的10倍，ADO.net在添加数据上的表现实在不尽如人意，这也跟我们项目底层写法有关。

　 　从上面的测试结果可以看出，除去EF在初次操作数据是延迟的3秒钟（初步认为是初始化时间），EF的平均效率是LINQ to SQL的6倍，是当前项目机制的4倍，这是非常可观的效率提升，不难理解为什么微软几乎放弃了LINQ to SQL，全力支持EF了。

【深 入分析为什么第一次执行Entity Framework非常慢的原因】（转）

第一次创建 ObjectContext并查询数据时耗费了大量的时间，原因是什么？有没有什么优化的方法？本文将给出一个合理的解释。

下面这个饼 状图给出了第一次创建ObjectContext并用其访问数据库时各种操作所占的时间比

从中可以看出仅仅 View Generation一个操作就占用了56%的时间，不过令人欣慰的是，这个操作只出现在第一次查询的时候，之后生成好的View会被缓存起来供以后使 用。一个View.cs文件的样本如下：

我们可以使用 EDMGen2.exe来自己生成View.cs，然后把它加入到工程中编译，这样会大大缩减View Generation操作所占的时间比。根据ADO.NET TEAM 的测试，自己编译View大概会节省28%的时间。不过我在自己电脑上测试的结果没有那么理想，大概是8%左右。