Question

entity framework 性能真那么差

Answer 1

说EF性能差的，目测是根本不会使用EF的，或者说是把EF用的的很烂的人。
EF目前是6.1.3。针对code first以及SQL脚本优化做了非常多的工作。举个简单的例子。现在估计还有大部分.NET程序员在使用数据脚本分页的时候还在用着古老的top分页吧？好一点的知道row_number。但是EF会根据你连接SQL版本(仅讨论SQLserver)进行不同版本的分页支持。例如sql2012以上的版本。EF会自动采用FETCH NEXT进行分页,fn和top的性能对比，这个就不说了。
再举个例子。之前给公司某同事擦屁股，有一个多表多关联复杂查询并且内部要实现一些函数操作。采用linq to ef编写的。测试反馈说查询速度巨慢。我打开sql profile看了一下。此君接近90行的linq,生成了2000行的SQL。于是我逐步重写。最后变为40行的Linq,生成60行的脚本,打开速度立马飞跃到毫秒级。
以上是说的读取性能方面的问题。下面说一下写的问题，目前EF对批量写批量UP操作的确支持不是很好(不要提addrange) 但是可以通过第三方EF插件实现对数据库的bulk操作。大量写的效率基本和在sql里进行bulk几乎差不多。
所以不是EF性能不好，而是你不会用罢了

Answer 2

模式决定一切，他底层的模式决定了，性能好不到哪里去。用得差的固然慢，用得好的性能确实有不错的提升，但是无论怎么样，这种映射的模式决定了他确定有相当的性能损耗，比如: 相对于存储过程来说，1、sql上行传输量大 2、输出一些无关的字段，这对于大表尤其明显，3对于一些复杂的逻辑，需要拿到数据到.net代码中处理，来来回回的交互远没有在存储过程中本地内存中处理快。4、对于一些需要使用事务，使用锁的地方，事务，锁占用的时间效率==都是问题，所以EF只适合一些小的应用，对于大的比较复杂，性能高的系统还是不适用，不是说EF不好，关键看应用场景，根据不同的场景选择最合适的技术架构才是最正确的。

Answer 3

自问自答玩的很嗨吧！
这东西烂是因为不可测，需要额外花费精力去关注运作的细节，要优化性能直接优化sql查询不直观么？

Answer 4

ef大而全，然而我发现ef没用武之地，ef性能现在提升很多，但是这是说预热后执行sql的性能，小项目哪里有多余的资源给你几十秒先预热，基本都是冷启动；大项目对性能要求又特别高，而且对于大项目来说EF真心不好动数据库，万一有需求变化能改死人