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
评测总结我的开发原则是,只要在我的能力范围内,不影响大局,要做就做到极致,这是一种追求。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。