EF Core vs LINQ2DB

Entity Framework Core recently got v1.1.0. Though it still lacks some critical features like "GROUP BY" SQL translation (see its roadmap) it's time to test it.

The following frameworks will be tested:

1. Entity Framework CodeFirst (LINQ query, models generated from DB)
2. Entity Framework (raw SQL query)
3. ADO.NET
4. LINQ to DB (LINQ query, model entities generated from DB)
5. LINQ to DB (raw SQL query)
6. Entity Framework Core (doesn't support raw SQL execution at this moment)

Hardware used: i5-4200H, DDR3-1600, Win 10 x64 1607.

Software used: SQL Server 2016 SP1, VS 2015, .NET 4.6.1, EF 6.1.3, LINQ to DB 1.7.5, EF Core 1.1.0.

And default Northwind database.

The tests are the same as in one of the previous articles.

Note: EF Core doesn't use "GROUP BY" in generated SQL, instead it processes it in memory. This can lead to high load on the database in production.

Context Initialization

EF Core's context initialization is twice faster than EF 6. It matters for simple and fast queries.

Simple TOP 10 query

Here and below the grey part of bar is context initialization.

We can see that EF Core is faster than EF 6 when running simple queries. Though it's faster than EF 6 both in context initialization as well as in everything else but it still slower twice than LINQ2DB in overall.

Depending on the usage it might not be so bad, because absolute time is low.

Simple TOP 500 query

Results are almost the same, but now EF Core not to far from ADO.NET and LINQ2DB.

Complex TOP 10 query

Almost no difference between frameworks, except EF 6 which is 2x slower than others.

Complex TOP 500 query

The complex query with many result rows makes all frameworks nearly the same (again except EF 6 which is 2x slower than others).

Conclusions

EF Core is faster than EF 6. It's a good thing. But it still can't use "GROUP BY" clause in SQL although it's 1.1.0 version released. It's bad.

Another bad thing about EF Core is that it doesn't support raw SQL execution. It almost doesn't matter for complex queries, but usually applications have many simple queries, and here EF Core is weak - it can't be optimized more. Change tracking doesn't affect selects, and the only way for optimization is raw SQL.

So, if performance is not significant then EF Core can be chose. Otherwise, it's even EF 6 might be more preferable because it supports raw SQL execution which will help in heavy queries.

And if performance is important, or if change tracking is not required, then LINQ2DB may be the best choice. LINQ2DB's LINQ queries are not very slower than raw ADO.NET even for simple queries. And if it's not enough then raw SQL can be used. LINQ2DB is not new, so it hasn't such plenty of bugs as EF Core now.

Raw results (Excel).

View project source code at GitHub.

Performance of LINQ to DB vs Entity Framework vs BLToolkit vs ADO.NET

Last years BLToolkit is being developed slowly. The reason is its author Igor Tkachev decided to write a new ORM - LINQ to DB.

He says it provides fastest LINQ database access. And it supports 12 database providers including MSSQL, SQLite, Postgres. And it supports mass UPDATE and DELETE, and Bulk Copy.

Also, LINQ to DB provides mechanism similar to EF Code First generator. It has T4 template that generates code structure from the database. All you need is to put connection string and execute T4 template.

BLToolkit also supports LINQ, but it's main strength is not only speed but also mapping.

Let's compare it with other ORMs.

These tests were performed on i5-4200H, DDR3-1600, Win 8.1 x64, SQL Server 2014, VS 2013, .NET 4.5, EF 6.1.2, BLTookit 4.2.0, LINQ to DB 1.0.7.1. Default Northwind database was used.

Used tests are the same as in previous article.

There were 6 methods tested to work with database:

1. DbContext CodeFirst (LINQ query, models generated from DB)
2. DbContext CodeFirst (raw SQL query)
3. ADO.NET
4. Business Logic Toolkit (raw SQL query)
5. LINQ to DB (LINQ query, models entities generated from DB)
6. LINQ to DB (raw SQL query)

Context Initialization

EF CodeFirst with LINQ query takes much more time that others. LINQ to DB with LINQ query and CF wih raw SQL take nearly the same time, and take 2-3 times more than other raw SQL. But anyway for complex queries it doesn't matter much.

Simple TOP 10 query

Here and below the grey part of bar is context initialization.

For simple query, LINQ to DB query using LINQ takes twice more time than for raw SQL. But anyway it's much faster than EF, and even slightly faster that CF with raw SQL.

Simple TOP 500 query

When number of result rows is not small, then even for simple query difference is not much. It's because mapping takes significant part of time, and compilation of simple LINQ query is not so much. And we can see that new architecture for linq2db is more faster than BLToolkit. Even LINQ query with linq2db is faster that raw SQL with BLToolkit. LINQ to DB with raw SQL query is the same speed as ASO.NET.

Complex TOP 10 query

LINQ to DB compilation is very fast. This makes its LINQ query speed almost the same as ADO.NET. EF CF with LINQ query takes twice more time than others.

Complex TOP 500 query

Complex TOP 500 query results are the same.

Conclusions

LINQ to DB is very fast both with raw SQL or LINQ query. For simple and small queries it's possible to use raw SQL instead of LINQ, but absolute time makes almost no difference.

LINQ to DB is good choice for ORM if you don't need change-tracking. And if you don't need all BLToolkit mapping capabilities (linq2db supports type-to-type mapping).

Raw results (XSLT).

View project source code at GitHub.