ORM慢吗？有关系吗？

Question

与存储过程相比，我真的很喜欢ORM，但有一件事我担心ORM会因为图层和抽象层而变慢。使用ORM会减慢我的申请吗？ 或者重要吗？

Answer 1

是的，这很重要。它使用更多的CPU周期，从而减慢了应用程序的速度。虽然听到了我...

但是，考虑一下：什么更贵？服务器硬件还是其他程序员？通常，服务器硬件比雇用另一个程序员团队便宜。因此，虽然ORM可能会花费您的CPU周期，但您需要少一名程序员来管理您的SQL查询，这通常会降低净成本。

要确定它是否值得，请计算或确定使用ORM保存的小时数。然后，计算出您在服务器上花了多少钱来支持ORM。将您按小时费率保存的小时数乘以服务器成本。

当然，ORM是否真的可以节省您的时间，这是另一场辩论......

Answer 2

  

ORM慢吗？

不是天生的。一些重量级的ORM可以为事物添加一般拖累，但我们并没有谈论数量级减速。

做什么让ORM变慢是天真的用法。如果您正在使用ORM，因为看起来很简单并且您不知道底层关系数据模型如何工作，您可以轻松编写对OO程序员来说似乎合理的代码，但会谋杀性能。

ORM是一个方便的工具，但你需要较低层次的理解（通常来自编写SQL查询）来配合它。

  

重要吗？

如果您最终一次为数千个实体中的每个实体执行循环查询，而不是单个快速连接，那么它当然可以。

Answer 3

ORM的速度较慢，并且会增加应用程序的开销（除非您特别知道如何解决这些问题，这不是很常见）。数据库是最关键的元素，应该围绕它设计Web应用程序。

许多使用Active Record或ORM的OOP框架，通常是开发人员 - 将数据库视为一种不重要的事后想法，并倾向于将其视为他们并不真正需要学习的东西。但是性能和可扩展性通常会受到影响，因为数据库需要大量征税！

许多大型网络应用程序已经停滞不前，浪费了数百万甚至数月甚至数年的时间，因为他们没有意识到数据库的重要性。数百个具有数百万条记录的并发用户和表需要数据库调优和优化。但我相信这个问题在少数用户和较少数据的情况下是显而易见的。

为什么开发人员如此害怕在性能关键时学习正确的SQL和调优措施？

Answer 4

在反对使用SqlCe的Windows Mobile 5项目中，我使用ORM模板从使用手动编码对象转换为代码生成（CodeSmith）对象。在此过程中，我的所有数据访问都使用CSLA作为基础层。

直接转换在本地测试中将我的性能提高了32％，几乎所有这些都是更好的访问方法的结果。

在更改之后，我们调整了模板（在Steve Lasker看到PDC的一些SqlCe性能之后），在不到20分钟内，我们的整个数据层得到了极大的改进，我们的平均“慢”调用从460ms变为〜 20毫秒。关于ORM的一个很酷的部分是我们只需要实现（和单元测试）这些更改一次，并且所有数据访问代码都已更改。这是一个惊人的节省时间，我们可能节省40个小时或更多。

如上所述，我们确实通过取出一堆不再需要的“等待”和“进展”对话而失去了一些时间。

我使用了一些ORM工具，我可以推荐其中两个：

• .NET Tiers
• CSLA codegen templates

他们两人都表现得相当不错，任何表现都没有引人注意。

Answer 5

我一直觉得没关系。您应该使用能够使您最有效率，响应变化的任何内容，以及最容易调试和维护的内容。

大多数应用程序永远不需要足够的负载来使ORM和SP之间的差异显着。并且有一些优化可以使ORM更快。

最后，一个编写良好的应用程序将使其数据访问与其他所有内容分离，以便将来从ORM切换到可能的任何内容。

Answer 6

  

ORM速度慢吗？

是（与存储过程相比）

  

这有关系吗？

否（除了您关心的速度）

我认为问题是很多人认为ORM是数据库的一个对象“技巧”，代码较少或简化了SQL使用，而实际上是......很好的对象 - 关系（DB） - 映射。

ORM用于将对象持久保存到关系数据库管理器系统，而不是（仅）替换或使SQL更容易（尽管它也能很好地完成）

如果您没有良好的对象模型，或者您正在使用报告，或者即使您只是想获取某些信息，ORM也不值得。

另一方面，如果你有一个通过对象建模的复杂系统，每个人都有不同的规则，并且它们会动态交互，你关心的是将信息保存到数据库而不是替换现有的SQL脚本，然后去ORM。 / p>

Answer 7

是的，ORM影响绩效，这是否最终取决于项目的具体情况。

程序员经常喜欢ORM，因为他们喜欢像Visual Studio这样漂亮的前端cding环境，不喜欢没有intellisense的原始SQL编码等。

除了性能损失之外，ORM还有其他限制 - 它们通常不会在100％的时间内完成所需的操作，增加了每次进行chhnge时必须维护和重新建立的额外抽象层的复杂性，还有一些缓存问题需要处理。

只是想一想 - 如果数据库供应商将SQL编程环境与Visual Studio一样好，并在db代码和前端代码之间提供更自然的链接，我们就不需要ORM了......我想最终可能会朝着那个方向发展。

Answer 8

是的，ORM会降低您的申请速度。取决于抽象的程度，对象模型与数据库的映射程度以及其他因素。问题应该是，您是否愿意花费更多的开发人员时间并使用直接数据访问或交换更少的开发时间来降低运行时性能。

总的来说，良好的ORM几乎没有开销，而且总的来说，它们被认为是非常值得的。

Answer 9

我发现“太慢”和“不太慢”之间的区别取决于你是否启用了ORM的第二级（SessionFactory）缓存。有了它，它可以在开发负载下处理得很好，但会在温和的生产负荷下压碎你的系统。打开第二级缓存后，服务器处理了预期的负载并且很好地扩展了。

Answer 10

ORM可以减慢一个数量级，不仅仅是因为它自己浪费了很多CPU周期，而且还使用了更多的内存，然后必须是GC-d。

然而，更糟糕的是，它不是ORM的标准（与SQL不同），而且我和大型ORM-s使用SQL效率低下，所以在一天结束时你还需要深入研究SQL以解决每个问题每当ORM弄得一团糟，你就必须调试它。这意味着你根本没有获得任何东西。

对于真正的生产级应用程序来说，这是非常不成熟的技术。非常有问题的事情是处理索引，外键，调整表以适应对象层次结构和非常长的事务，这意味着更多的死锁和重复 - 如果ORM知道如何处理它的话。

它实际上使服务器的可扩展性降低，从而增加了成本，但这些成本在开始时没有被提及 - 有点不方便的事实:-)当某些事情使用比最佳值大10-100倍的事务时，无法扩展SQL端所有。再谈论严肃的系统，而不是家庭/玩具/学术用品。

Answer 11

明显的答案：这取决于

ORM很好地将程序员与SQL隔离开来。这实际上取代了平庸的，计算机生成的查询，用于程序员可能给出的灾难性错误查询。

即使在最好的情况下，ORM也会做一些额外的工作，加载它不需要的字段，显式检查约束，等等。

当这些成为瓶颈时，大多数ORM会让你支持他们并注入原始SQL。

如果你的应用程序非常适合对象，但对于关系来说并不那么容易，那么这仍然是一个胜利。相反，如果您的应用程序非常适合关系模型，那么ORM代表了可能的性能瓶颈之上的编码瓶颈。

我发现大多数ORM特别令人反感的是他们对主键的处理。大多数ORM都要求pk用于触摸的所有内容，即使它们没有令人满意的用途。示例：作者应该有pk，博客帖子应该有pk，但作者和帖子之间的链接（连接表）不是。

Answer 12

由于抽象层，ORM总是会增加一些开销，但除非设计糟糕的ORM应该是最小的。如果您正确地执行此操作，实际查询数据库的时间将比ORM基础结构的额外开销多很多倍，例如，在不需要时不加载完整对象图。一个好的ORM（nHibernate）也会为您提供许多针对数据库运行的查询的选项，因此您也可以根据需要进行优化。

Answer 13

使用ORM通常较慢。但是，您获得的生产力提升将使您的应用程序更快地运行和运行。您节省的时间可以用于查找导致最大速度减慢的应用程序部分 - 然后您可以花时间优化您在开发工作中获得最佳回报的区域。仅仅因为你决定使用ORM并不意味着你不能在代码中真正从中受益的部分使用其他技术。

Answer 14

ORM可能会更慢，但这可以通过它们缓存数据的能力来抵消，因此无论选择多快，你都不能比从内存中读取更快。

Answer 15

我从来没有真正明白为什么人们会认为这个速度较慢或者速度较慢...我说的是真机。我的结果好坏参半...我已经看到存储过程的执行时间比ORM慢得多，反之亦然。但在这两种情况下，性能都是由于硬件的差异造成的。