What are the differences in performance issues when using querys with EF vs ADO

4

What is the difference in performance when using the query methods the base SqlQuery<TElement> and ExecuteSqlCommand of EntityFramework in relation to directly using ADO.NET ?

If there is a significant difference in performance, this is due to data processing performed by the EntityFramework before accessing the database or EntityFramework also causes impacts on database?

Using ADO.NET to perform a select

using (SqlConnection connection = new SqlConnection("connectionString"))
{
    using (SqlCommand command = new SqlCommand("SELECT * FROM TABLE", connection))
    {
        SqlDataReader reader = command.ExecuteReader();
        while (reader.Read())
        {
            ///...
        }
    }
}

Using Entity Framework to perform a select with SQLQuery

context.Database.SqlQuery<Table>("SELECT * FROM TABLE");

Using ADO.NET to perform an insert statement

using (SqlConnection connection = new SqlConnection("connectionString"))
{
    using (SqlCommand command = new SqlCommand("INSERT INTO TABLE VALUES ('foo', 'ba', GETDATE())", connection))
    {
        int records = command.ExecuteNonQuery();        
    }
}

Using EntityFramework to perform an insert statement with ExecuteSqlCommand

context.Database.ExecuteSqlCommand("INSERT INTO TABLE VALUES ('foo', 'ba', GETDATE())");
    
asked by anonymous 06.04.2016 / 13:54

1 answer

1

There is a old comparison shown the performance of some ORMs with raw access. The Entity Framework has improved a lot over the years, especially EF Core , but there is still a natural overhead in it. More benchmark .

Obviously these comparisons depend a lot on what is being accomplished, what strategy, the specific settings are being used. Although everyone wants magical information about which is faster, you can not say anything about performance without doing specific tests in real situation.

The way used in EF code is unusual, in the background it's almost not using what EF has to offer, it does not use it as a full ORM, which can be a good and equalizing performance. With equal strategies there will not be much performance difference, at least to set up the query which is one of the performance costs.

When you choose to write your own queries SQL they will determine the bulk of your performance. It is very common for the programmer to be able to write better queries than an ORM can write from a C # expression. Again, it will vary from case to case.

For those who choose EF, an optimization strategy is certainly to abandon its normal syntax that abstracts SQL and uses its own query . Of course, this situation may prevent one of the advantages of ORM, which is to allow database abstraction (something the person does not usually need but generalizes prematurely)

If it is to be used always like this, it probably has little advantage in using EF, it is better to use a simpler ORM such as the Dapper already mentioned in the link above or even pure ADO.Net

Obviously other things can make a difference depending on the context applied. We do not even know how EF is set to say anything. Even knowing it will be difficult to make definitive statements.

The question will always be: are you having performance problems or just want it to be faster what is already fast enough?

    
06.04.2016 / 14:20