实体框架4和实体框架3.5的性能如何？

Question

我在使用EF 3.5时，页面上的一个查询至少需要半秒钟才能执行。当我使用存储过程时，速度明显更快。这是一个非常复杂的查询。在即将推出的EF 4.0中，会有任何性能改进吗？EF 4.0在性能方面真的比3.5更好吗？

- Luke101

---

顺便问一句，你有没有查看存储过程和EF 3.5生成的执行计划之间的差异？ - Kane

Answer 1

短暂的答案是现在还为时过早。.Net团队几乎完全专注于性能，直到4月12日的发布必须完成和本地化。此外，“更快”是什么意思？更快可以从许多方面来看，例如：

• Entity Framework 4.0有新功能, 其中对象追踪的改进可能意味着巨大的收益，因为您不必自己手动完成...无论如何，至少开发速度更快。
• 如果之前根本不起作用，那么具有POCO 支持的轻量级对象也可能意味着在处理大量对象时移动的内存要少得多。无论从数据库获取时额外属性的成本有多小，实例化和跟踪它们都有成本（加载时间和内存消耗）。

在你的情况下，除非是非常复杂或高容量查询，半秒钟对任何事情来说都是一个很长的时间......你是否查看过数据库中花费了多少时间，以及.Net获取数据后花费了多少时间？如果你大部分时间不在SQL中，那么Net 4.0中基本的反射改进应该会提供一些速度改进......但是如果你所有的时间都花在SQL上，那么它帮助不大。你的性能问题的主要原因可能是生成的SQL的索引而不是Entity Framework的填充性能。

我会遵循Kane的评论，查看它为你的查询生成的SQL，你能否将此和存储过程发布出来，这样我们就可以找到问题所在？

- Nick Craver

Answer 2

来自ADO.NET博客：

自定义查询 - 添加对现有LINQ运算符的支持，识别更多的模式与LINQ一起编写模型定义函数以及使用这些函数的能力，以及创建和自定义查询的其他方式。

SQL生成可读性改进 - 改进生成的查询的可读性以及TSQL性能优化，使其更容易理解正在发生的事情。

因此，这两个要点意味着您可以看到它如何从LINQ生成查询的改进。

然而，ORM很难超越您从头开始编写的查询，因为它必须适应许多不同的情况，并且通常默认为最常见的情况。当我使用EF 3.5时，它似乎产生了一些非常有效的联接SQL，可能是我从ORM中看到的最好的结果，因此您可以希望在4.0中放弃SP。

如果你有一个存储过程，我猜它是一个大查询 - 每次将这个 SQL 文本发送到服务器会导致大量的网络流量，这可能是你考虑或没考虑过的另一件事。显然，在同一台服务器或内部网络中，这是一种“削发减肥”的优化风格。

- Chris S

Answer 3

当涉及到非常复杂的查询时，我没有看到任何证据表明L2S、NH或EF可以生成比我在存储过程中编写的更好的查询计划。我喜欢ORM（尤其是NH），但仍然有时候存储过程的执行时间可以击败ORM。

- Jarrett Meyer