.net LINQtoSQL比LINQtoEntities快吗？

我正在和我的一个同事讨论。我们在工作中使用LINQtoSQL，我对这项工作有点陌生，所以我问他为什么我们不使用LINQtoEntities？他提出了一些论点，其中一个论点是“因为LINQtoEntities比LINQtoSQL慢”。我对此有点怀疑，我确实知道LINQtoEntities更复杂，并且有额外的特性，但我不明白为什么它更慢

---

Linq对实体的速度慢吗？对于这样的论点，什么样的回答才是好的？

这可能是由于早期版本的Entity Framework存在性能问题

在早期的版本中，在实体框架中，查询存在很多问题，这些问题的翻译效果很差。后来的版本解决了许多这些问题，所以现在我认为，从性能角度来看，这可能是最好的

---

也就是说，这实际上取决于您正在测试什么-基准测试和评测是唯一的判断方法。Linq到SQL对于某些操作会更快，但对于其他操作，EF也会更快。也就是说，EF现在允许更多的机会来解决限制和问题，因此，随着时间的推移，可能会更加可调。

就纯性能而言，LINq到SQL应该稍微快一点，因为它使用一层映射，而LINq到实体有两层映射，额外的映射可能会带来性能成本

---

但是，您应该在自己的利用率环境中进行一些基准测试，因为性能差异在大多数情况下都不会被注意到…

请您的同事向您展示基准测试。这要视情况而定！-一如既往：-）Linq到SQL是一个非常简单的单层映射-表在.NET中成为一个类。实体框架要复杂得多，您可以将多个表映射到单个类。所以对于简单的场景：是的，LINQtoSQL肯定会快一点。但是：EF（至少在v4中）允许非常好地集成存储过程，这可以再次大大提高您的性能-L2S使用存储过程有点凌乱和笨拙。。。因此，这可能对EF4也是一个好处……而且，我认为EF4生成的SQL通常更“成熟”，可能比Linq to SQL生成的某些SQL语句快一点。但是差异可能非常罕见，并且只发生在特定的用例中……@Steven虽然我同意这是一个很好的理由，不选择它进行新的开发，但它实际上不会对其性能产生影响；）+1.还值得注意的是，Entity Framework的下一个版本承诺自动缓存查询，这可能会使其在当前版本和LINQ to SQL的基础上大大提高性能。