How many times faster is ADO.NET than EF?

Question

.NET

How many times faster is ADO.NET than EF, at what base sizes is it worth using ADO.NET instead of EF?

Answer 1

www.entityframeworktutorial.net/what-is-entityfram...
there is this phrase
Entity framework is an Object/Relational Mapping (O/RM) framework. It is an enhancement to ADO.NET that gives developers an automated mechanism for accessing & storing the data in the database.
In general, the meaning of all this, EF is an extension to ADO.Net for accessing the database.
And if it is quite specific, then the fastest way is direct SQL queries to the database. The new EF7 is actually rewritten from the ground up, and is highly optimized for speed when it comes to querying the database. It's up to you to choose whether to make the count simpler, safer (using EF eliminates such a thing as SQL Injection) or a little bit faster (or maybe a little more, EF6 had problems with compiling complex selections and queries were executing for a long time).

Answer 2

If you want to hear the answer in the form - "in 2", "in 5", "in 1.5", then I have to disappoint you. EF is a fancy, sophisticated wrapper around ADO.NET with the sole purpose of making your life a little easier if you're new to database techniques. Technically, it generates an SQL query based on your scripts and executes it on the basis of the same ADO.NET classes and methods as you do. If you are good at writing SQL scripts, then the difference in performance will only be in wrappers. If you write scripts badly and sculpt cursors, extra JOINs and a bunch of strange instructions, then take EF better. If you write shitty server code, where you first drag the entire data table to your application server, filter and sort it there, and then cut off the right piece, then EF will not save you either. In this case, a fantastically inefficient query will be generated with, possibly forced, additional. requests, and at the same time, the application itself will receive tasks that it does not need for nothing. There is no good answer like "with a million records, write with your hands, and if it's less than EF". It is necessary to look globally at the application architecture and interaction with data.