为什么在直接选择语句中Entity Framework的执行速度比Dapper快 [英] Why Entity Framework performs faster than Dapper in direct select statement

问题描述

我不熟悉使用ORM处理数据库，目前我正在制作一个新项目，必须决定是否要使用Entity Framework或Dapper。我读过很多文章说Dapper比Entity Framework快。

I'm new to using ORM in dealing with database, Currently I'm making a new project and I have to decide if i'll use Entity Framework or Dapper. I read many articles which says that Dapper is faster than Entity Framework.

因此，我制作了2个简单的原型项目，一个使用Dapper，另一个使用Entity Framework，其中一个功能获得一个表中的所有行。
表模式如下图所示

So I made 2 simple prototype projects one using Dapper and the other uses Entity Framework with one function to get all the rows from one table. The table schema as the following picture

以及两个项目的代码如下

and the code for both projects as the following

Dapper项目

System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
IEnumerable<Emp> emplist = cn.Query<Emp>(@"Select * From Employees");
sw.Stop();
MessageBox.Show(sw.ElapsedMilliseconds.ToString());

用于实体框架项目

System.Diagnostics.Stopwatch sw = new System.Diagnostics.Stopwatch();
sw.Start();
IEnumerable<Employee> emplist = hrctx.Employees.ToList();
sw.Stop();
MessageBox.Show(sw.ElapsedMilliseconds.ToString());

仅在我第一次运行项目多次尝试上述代码后，精巧的代码会更快在这第一次之后，我总是从实体框架项目
中获得更好的结果，我还尝试了以下关于实体框架项目的声明来停止延迟加载

after trying the above code many times only the first time I run the project the dapper code will be faster and after this first time always I get better results from entity framework project I tried also the following statement on the entity framework project to stop the lazy loading

hrctx.Configuration.LazyLoadingEnabled = false;

但除第一次外，相同的EF执行速度更快。

but still the same EF performes faster except for the first time.

尽管网络上的所有文章都说相反，但在此示例中，谁能给我解释或指导EF更快的原因

Can any one give me explanation or guidance on what makes EF faster in this sample although all the articles on the web says the opposite

更新

我已将实体示例中的代码行更改为

I've changed the line of code in the entity sample to be

IEnumerable<Employee> emplist = hrctx.Employees.AsNoTracking().ToList();

停止实体框架缓存，并停止缓存后，dapper示例的性能更好（但差别不大）

using the AsNoTracking as mentioned in some articles stops the entity framework caching and after stopping the caching the dapper sample is performing better, (but not a very big difference)

推荐答案

ORM（对象关系映射器）是一种工具，可在您的应用程序和数据源之间创建层，并向您返回关系对象，而不是
（对于您使用的c＃）是ADO.NET对象。这是每个ORM都要做的基本事情。

ORM (Object Relational Mapper) is a tool that creates layer between your application and data source and returns you the relational objects instead of (in terms of c# that you are using) ADO.NET objects. This is basic thing that every ORM does.

为此，ORM通常执行查询并映射返回的 DataReader 转到POCO类。精简版仅限于此处。

To do this, ORMs generally execute the query and map the returned DataReader to the POCO class. Dapper is limited up to here.

为进一步扩展此功能，某些ORM（也称为完整ORM）会做更多的事情，例如生成查询以使您的应用程序独立于数据库，为将来的调用缓存数据，为您管理工作单位等等。所有这些都是好的工具，可以为ORM增值；但它伴随着成本。实体框架属于此类。

To extend this further, some ORMs (also called "full ORM") do much more things like generating query for you to make your application database independent, cache your data for future calls, manage unit of work for you and lot more. All these are good tools and adds value to ORM; but it comes with cost. Entity Framework falls in this class.

要生成查询，EF必须执行其他代码。缓存可以提高性能，但是管理缓存需要执行其他代码。对于工作单元和EF提供的任何其他附加功能也是如此。这一切都为您节省了编写额外代码的费用，而EF承担了成本。

To generate the query, EF have to execute additional code. Cache improves the performance but managing the cache needs to execute additional code. Same is true for unit of work and any other add-on feature provided by EF. All this saves you writing additional code and EF pays the cost.

而成本是性能。由于Dapper做的很基础，因此速度更快。但您必须编写更多代码。由于EF的功能远不止于此，因此它（慢一点）。

And the cost is performance. As Dapper does very basic job, it is faster; but you have to write more code. As EF does much more than that, it is (bit) slower; but you have to write less code.

那为什么测试结果相反？

因为测试是

So why your tests show opposite results?
Because the tests you are executing are not comparable.

完整的ORM具有许多良好的功能，如上所述。其中之一是UnitOfWork。跟踪是UoW的职责之一。首次请求对象（SQL查询）时，它将导致数据库往返。然后将该对象保存在内存缓存中。完整的ORM跟踪对此已加载对象所做的更改。如果再次请求相同的对象（在同一UoW范围内的其他SQL查询中包含已加载的对象），则它们不会进行数据库往返。相反，它们从内存缓存中返回对象。这样，可以节省大量时间。

Dapper不支持此功能，因此它在测试中的执行速度会变慢。

Full ORMs have many good features as explained above; one of them is UnitOfWork. Tracking is one of the responsibilities of UoW. When the object is requested (SQL query) for first time, it causes round trip to database. This object is then saved in memory cache. Full ORM keeps track of changes done to this already loaded object(s). If same object is requested again (other SQL query in same UoW scope that include loaded object), they do not do database round trip. Instead, they return the object from memory cache instead. This way, considerable time is saved.
Dapper do not support this feature that causes it to perform slower in your tests.

但是，这样做的好处仅在相同对象多次加载时适用。另外，如果加载到内存中的对象数量过多，则会降低整个ORM的速度，因为检查所需的时间会更长。同样，这种收益取决于用例。

But, this benefit is only applicable if same object(s) loaded multiple times. Also, if number of objects loaded in memory is too high, this will slow down the full ORM instead as then the time required to check the objects in memory will be higher. So again, this benefit depends on use-case.

这篇关于为什么在直接选择语句中Entity Framework的执行速度比Dapper快的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！