entity framework 性能真那么差？
0
悬赏园豆：50
[已解决问题]
解决于 2013-12-30 14:56
项目数据库的操作用的EF框架，在网上搜索一些资料的时候屡屡发现说EF效率低劣，问题百出的内容。希望听到有过实际经验的大侠的客观评价。或者说一些提高EF效率尽量接近单纯使用ADO.NET的效率的注意事项和方法
最佳答案
0
我现在所做项目就是用EF，数据量下平均下来每个表几十万数据，单纯从性能上来说EF效率相比ado.net 确实要慢点，因为转化成sql要时间，而且相比原始的sql语句，显得有些冗余。偶尔也踩到过EF的坑如 where(o=>o.id==id).FirstOrDefault() 与 FirstOrDefault(o=>o.id==id) 这两句看似效果是一样的，但是实际结果却是很大的差距，生成的sql语句也不一致。这些都只是小问题的，注意写法就行了，EF带来的好处更多的是模式上的变化，把数据变为对象来处理，提升开发效率，当然还有延迟加载，与缓存。评价一个东西的好坏不能单一的评价，要综合来看。
收获园豆：30
是呀，模式上的变化。却是方便了不少，大侠说的这些区别我会仔细试试，看看生成的语句再来找问题。谢谢提醒。这样看来还是要加深对他的了解。别采坑。满足一般的系统没问题。踏实多了
问一下,where(o=>o.id==id).FirstOrDefault() 与 FirstOrDefault(o=>o.id==id),会有什么差距呢,哪个效率更高一些?
@慕容枫: 你是猪啊，明显是第一个高啊，第二个做了排序再取，第一个先取再排序，一般情况下小数据量的时候的效率影响我们忽略，数据量上来比如说上万了之后效率的差别就明显出来了，更不要说百万这种级别了
@TommyBiteMe:
骂人之前别想当然了，自己做个循环做时间统计看一下好么，直接firstordefault比where效率要高四分之一
其他回答(4)
0
通常说这种话的人，基本是属于站着说话不腰疼的。
如果你打算帮12306开发订票网站，那效率一定很重要。
亿万级、千万级、百万级、十万级、几千、几百数量级的访问为啥要用不同的技术，不是因为亿万级的技术解决不了几百、几千级别的问题，而是因为他们成本太高。
通常所有的技术都要在易用性和性能方面进行权衡。
问你这个问题的人，通常情况下，EF的性能问题不会造成影响。
通常情况下的应用时你击键1秒，系统反应0.01秒，你看清楚屏幕上的字3秒~1分钟。
所以系统反应提高到0.001秒或是0.000001秒，对你是没有意义的。
通常的性能测试会对0.01秒重复10万次，来体现他的慢。实际应用中你要开发淘宝或是12306之类的就需要了。
不过你那时应该不会问这个问题了。
换另外一个角度说，就是，如果你接到一个系统，客户打算花费少于10~50万，你们打算花费少于3~12个月人工，这个性能问题也是不需要考虑的。
EF和ADO.NET性能差别就好像是你买电脑，是I3还是I7，速度的差别，还没到486和I7速度差别这么多。
通常我见到的大部份的系统性能问题反而是出现在拙劣的系统设计和数据库设计上面。技术方面，微软并没有你想象中的那么差。
收获园豆：10
大部份的系统性能问题反而是出现在拙劣的系统设计和数据库设计上面。谢谢
@大芝麻: 12306是典型的SSH架构。举这个例子是否有点欠妥、、、:-D？其实淘宝，和12306都有用orm框架的，瓶颈根本不会出现在这些地方（参考：大型网站架构）淘宝架构师写的。这种大型完整，缓存就会阻挡80%-90%的数据库交互，加上其他一些分布式均衡相关的技术。来解决的，至于数据库读写、、只要缓存层没有有效的命中，你无论如何都扛不住的、、、而且orm效率并不是你想象的那么差，你测试用emit委托之类方式字段和直接赋值，效率基本一个数量级，加上一些本地缓存，效率完全可以与直接sql媲美。但是效率上就完全不是一个档次的了。
12306是典型的SSH架构。举这个例子是否有点欠妥、、、:-D？其实淘宝，和12306都有用orm框架的，瓶颈根本不会出现在这些地方（参考：大 型网站架构）淘宝架构师写的。这种大型完整，缓存就会阻挡80%-90%的数据库交互，加上其他一些分布式缓存，负载均衡相关的技术，来解决的。至于数据库读写、、 只要缓存层没有有效的命中，你无论如何都扛不住的、、、而且orm效率并不是你想象的那么差，你测试用emit委托之类方式组装对象和直接赋值（还有其他一些sql映射之类的），效率基本一个 数量级，加上一些本地缓存，效率完全可以与直接sql媲美。但是开发效率上就完全不是一个档次的了。
1
1楼的回答真的在胡扯了，对于12306或者淘宝这样的网站来说，就算你直接用原生的sql也一样是撑不住的。这个必须在底层就对数据进行拆分成若干若干个库才能解决。对于大型网站必然要采用多数据库集群，中间有更复杂的数据跳转，实际上速度可能比EF还要慢，但是靠的一大堆机器去堆上去。比如新蛋据我所知光sql server就有80多台。
EF性能要看版本，EF5对性能做了很好的优化，解决了生成的sql语句比较良好，同时具有编译缓存，换句话说，当第二次执行的时候，就没有转换sql这个过程了，而是直接采用缓存的sql语句。
从性能上来说，EF比起原生的ADO.NET来说慢很少一点点。
在使用的时候，要注意通过Log分析生成的sql语句是否OK，虽然EF5解决了大部分问题，但是并不意味着极其复杂的查询仍然能够生成非常良好的sql语句，需要自己分析瓶颈，如果发现类型情况，解决起来也很简单，封装成一个存储过程然后在EF里面调用就好了。
用EF6还有一些对存储过程的良好支持。
所以用EF是个很好的选择，但是要用到好处，别一条路走到黑，要理解其场景。
收获园豆：10
啥叫胡扯？我只是想表达说，应用不到一个层次，EF的性能不需要考虑而已。
很多的测试都是拿一个数据，循环10万次测试性能，通常的应用，没到高并发的情况，
优先考虑开发速度，先完成再优化，这是一个原则。
楼主的情况是担心性能象安装WIN7在286电脑上（你可能要反驳说安装不上去是吧？)
弄成存储过程还真没试过。谢谢提醒，不过我用的是3.5不知道是不是支持EF5
@爱编程的大叔: 还是扯。应用的规模更多的要和架构设计有关，EF这种小东西根本谈不到那个层面。“优先考虑开发速度，先完成再优化，这是一个原则。”这句话更是瞎扯，通常一开始不考虑优化的最后都会死的很惨。在开发指出你就要考虑性能的问题。
@大芝麻: 直接用EF6吧，这都什么年代了。很多时候存储过程是必须的。
@ocean: 3.5能用EF6吗，是安装还是怎么，求指教。本人各种菜鸟初学
@大芝麻: EF6是4.5，这都什么年代了，还用.NET3.5，装VS2013就好了。一般用EF，肯定都是以服务端程序为主，在服务器上装个.NET4.5不难吧。
0
还有一个是，因为ef查出来的会保存状态，SaveChanges的时候更新到数据库；
如果是纯粹的查询，可以使用AsNoTracking 。
0
EF就适合做demo,实际项目中作用很小，坑的地方很多，很多编程基础不好的人拿着当神器，把很多项目都给拖垮了，被外界认为C#性能差的罪魁祸首。最让人可笑的是长时间没有人访问第一次启动很慢，导致访问超时，网上找了很多解决办法都是治标不治本，这个问题会导致实际项目中像外部接口，app端都会导致很多问题，如果真的了解映射和实体原理，自己写个实体框架没有想象中的那么能，推荐用T4模板或者codesimth生成一套自己的框架。dos.orm就是最好的例子，推过数据库表生成实体、视图。生成单表的增删改查。建议还在用EF的人，尤其是项目几乎没什么人访问的，没有在实际项目中吃过EF亏的人，你们不要误导年轻人。怎么不算demo? 最少也的日活跃用户有个几千人在用的项目吧。
