EntityFramework、Dapper vs 草根框架性能

EntityFramework、Dapper vs 草根框架性能

扯淡

当前市面上 ORM 很多，有跑车型的，如 Dapper，有中规中矩型的，如 Mybatis.Net，也有重量型的，如 EntityFramework 和 NHibernate，还有一些出自草根之手的，如 Chloe.ORM。各式各样，层出不穷。试问，为何要重复造轮子？很简单，咱来自火星，目前地球上还没一款轮子适合咱这辆火星车~

为加深对各个 ORM 框架的了解，同时也想看看咱自己的框架性能如何，也可以让对 Chloe 感兴趣的同学有所了解，今儿，做个性能比较测试。测试对象为大家较熟悉的 EntityFramework 和有“性能之王”之称的 Dapper，以及草根框架 Chloe.ORM。

导航

基本介绍

测试内容

测试指标

测试环境与准备

测试方案

映射能力测试

查询能力测试

测试2.1

测试2.2

评测总结

关于 Chloe.ORM

结语

基本介绍

EntityFramework：EntityFramework 是微软官方提供的 ORM，俗称 EF，拥有坚不可摧的后台，可谓无人不知，无人不哓。其对 Linq 完美支持，功能丰富，但 EntityFramework Core 之前的版本，一直被业界人员贴上笨重、不可控、性能差的标签，很多人 Hold 不住它。可见，EntityFramework 的伯乐不多啊！不知道 EntityFramework Core 变化了多少，期待！ 本文测试使用的版本是 EntityFramework 6.1。

Dapper：Dapper 的背景同样不简单，目前支撑国外知名网站 stackoverflow 的数据访问层，其知名度也很高。在众多 ORM 中，堪称性能之王。作为一款微型 ORM，很受国内开发者的欢迎，毕竟经过大网站 stackoverflow 的考验。很多自主开发的 ORM 做性能测试，都会选择 Dapper 作为比较对象。Chloe.ORM 也不例外，哈哈！

Chloe.ORM：草根框架，初生牛犊。点击查看更多介绍...

测试内容

本次只对各 ORM 查询效率做评测。ORM 的性能损耗主要在 DataReader 向实体转换和生成 sql 语句这两过程，因此，本次测试的内容就考察以下两方面：

1.映射能力。

2.查询能力(由于无法仅测试 sql 生成阶段的性能，所以这点测试包括 sql 生成和映射能力)，即一个完整的查询。

测试指标

1.速度。即执行相同的查询所用时 。
2.GC 回收次数。即执行相同的查询 GC 执行回收次数。GC 次数越多说明程序运行内存开销越大。本指标测试通过 vs2013 自带的性能分析工具，它可以自动帮我们分析统计程序运行分配的内存以及 GC 回收次数，不懂的同学可以去了解下。打开 vs，分析 --> 性能与诊断 --> 内存使用率。

测试环境与准备

机器：戴尔 xps13 笔记本，CPU 为 i7-4510U，内存8G，win 10系统。
表：

View Code
运行效果图：

View Code
运行效果图：

View Code
运行5次，得到以下结果：

	ChloeQueryTest(ms)	ChloeSqlQueryTest(ms)	DapperQueryTest(ms)	EFLinqQueryTest(ms)	EFSqlQueryTest(ms)
第1轮	15281	11858	11981	31394	19309
第2轮	15194	12177	12314	31464	18161
第3轮	15967	12348	12366	31082	18030
第4轮	15371	11793	12479	32314	18356
第5轮	15350	11921	11937	35023	18356
平均	15411	12019	12215	32255	18442

GC 情况：

	ChloeQueryTest	ChloeSqlQueryTest	DapperQueryTest	EFLinqQueryTest	EFSqlQueryTest
GC回收次数	111	41	47	368	205

看起来改后测试数据较测试2.1稍微提升了点，提升幅度最明显的就是 EF，时间减少近 10 秒，GC 次数也减少了很多。如此看来，EF 创建和销毁 DbContext 上下文也是个挺耗性能的环节。不测还真不知道。不过， EF 的测试结果仍然不尽人意，EFLinqQueryTest 耗时依然比同为对象化查询的 ChloeQueryTest 多出一倍的时间，GC 次数是 ChloeQueryTest 的3倍还高。而且作为 EF 原生 sql 查询的 EFSqlQueryTest 在耗时、GC次数上居然比 ChloeQueryTest 要差，有点说不过去~真想知道 EF 内部做了什么不为人知的工作！

DapperQuery 和 ChloeSqlQuery 都是原生 sql 查询，在测试2.1中 DapperQuery 稍微快点，但在测试2.2中 ChloeSqlQuery 实现了反超。仔细想想，其实也不难理解，Chloe 的 DbContext 创建会伴随很多对象的创建，也耗不少资源，在测试2.2中，只创建了一个 DbContext 对象，随之，各方面提升也是肯定的。ChloeQuery 跟前两者压根没可比性，毕竟前两者没任何解析和生成 sql 过程，ChloeQuery 相对慢那是必然的。慢的那几秒就是用于解析 lambda 和生成 sql 。鱼和熊掌不可兼得，想要获得开发方便，性能损耗在所难免！

EF…“名副其实”的慢，不说了，都是泪- -。跪求大神来给 EF 正名！

结论：

1.速度：取平均值，EFLinqQuery < EFSqlQuery < ChloeQuery < ChloeSqlQuery ≈ DapperQuery

2.GC 次数：EFLinqQuery < EFSqlQuery < ChloeQuery < DapperQuery < ChloeSqlQuery

评测总结

映射能力：从 DataReader 向实体转换过程，Dapper 和 Chloe 都是利用 Emit 动态生成委托的方式，我相信 EF 也是这样。因此，在创建实体和属性赋值环节3者都相当。但不同的是，Chloe 在读 DataReader 数据的上做到了极致，所以在映射转换性能上相对比 Dapper 和 EF 要高些。Dapper 和 EF 则差不多。其实，速度上3者都相当，主要差别就是在内存开销上。

查询能力：查询能力是指框架执行一次完整的查询所耗时多少与内存开销大小。从测试2.1和测试2.2测试结果数据中我们可以看到，Dapper 和 Chloe 的原生 sql 查询性能几乎一样，差距不大，Chloe 的对象化查询较前两者稍微差点，主要是生成 sql 过程比较消耗性能。EF “不负众望”，以垫底的姿势存在，无论是在速度还是GC次数上都比前两者差一大截。EF 的映射能力其实不差(从映射能力测试数据中可以知道)，查询速度之所以慢，毫无疑问，问题出现在执行 sql 之前的环节。不过，EF 完美支持 Linq，丰富强大的功能着实让众多草根框架望尘莫及，希望 EntityFramework Core 版本性能有所大幅度提升。

关于 Chloe.ORM

我的开发原则是，只要在我的能力范围内，不影响大局，要做就做到极致，这是一种追求。Chloe.ORM 还有部分地方可以优化，但优化后对性能提升也不会很大，最近忙，也懒得折腾了。目前框架整体架构、功能都已经稳定，现在只支持 SqlServer，接下来的发展目标是支持 MySql，对 Chloe 感兴趣的同学可加入《.NET技术共享》群(群号：325936847)。为防止一些不相干人等混入群内，申请加群时需要您回答问题，只要你愿意，即可进群！谢谢合作。

关于源码，目前很缺乏注释与规范，一些类、方法以及变量的命名不是很好(英文，硬伤- -)，给对源码感兴趣的同学阅读带来很大的困扰，在此说声抱歉。往后，我会适当的加上一些注释。很多时候，除了一些极其关键点，我一般不会去写注释，特别是开发阶段，代码变换太频繁，维护代码的同时还要维护相应的注释，太幸苦，咱吃不消。所谓好代码就是最好的注释，像我这种懒人，不习惯注释，如果代码也不好好写的话，回过头我自己读自己的代码我估计都读不懂。因此，不写注释，也形成了一种自我逼迫，促使我必须把代码写得干净利落、优雅、易读。如果有必要，往后有空我也可以出篇 Chloe.ORM 框架内部架构设计和实现介绍的文章。

结语

本次测试并不是想证明谁好谁坏，只是想通过对比去了解各个 ORM 之间在性能上的差异，以便我们更好的为项目做技术选型。一样东西，存在必然有它存在的价值，项目开发，选择合适的框架才是重要的。Dapper 堪称性能之王，但它极度依赖手写 sql，开发效率低，容错率不高，如果一个项目不是高性能要求，选择一个快速开发框架就好，短时间内完成项目才是主要的。我们要做的就是利益最大化。实际上，并非个个项目都是 stackoverflow！倘若一个项目数据层用 Dapper 也好，用 EntityFramework 也罢，在同样的服务器上跑，都可以完美运行，用户完全感觉不到差别，我们为何不选开发效率高的 EntityFramework 呢？就目前，我们公司里部分项目，用户群体不是面向大众，我们就是用 EntityFramework，用它开发效率就是高，项目进展快，我们没理由用其它框架，很简单。

作为一名开发人员，很多时候真正的价值并不是你代码写得多好，程序运行多快，而是如何能在同样的时间内给用户、公司、社会带来最大的收益。

ps：所有的测试代码都已同步在 GitHub，地址：https://github.com/shuxinqin/Chloe/tree/master/ChloePerformanceTest。