The performance of an application is always a major concern when you are developing an enterprise application. When thousands of users will simultaneously hit your application, then getting good performance and required throughput depends a lot on your application's architectural design. This partly depends on how you are connecting to the database for fetching the data in your application. There are multiple ways always available, but we must choose the best of all the alternatives available when we don't want to miss out on performance.
When talking about performance, many of you would already know Entity Framework is much slower than the other two alternatives. The only advantage of the Entity Framework is the fastest implementation. When you are using a SQL profiler for running queries using Entity Framework, you can easily analyze that there is always huge room for optimization. Even for a very small operation, in EF, it executes more code than is actually required. So, I do not even consider Entity Framework when we talk about the performance of a huge application.
Now, the race is between Dapper and ADO.NET. Well, recently, we did a project using Dapper. Implementation-wise Dapper is easier than ADO.NET implementation. We started analyzing the application performance and throughput. But we found that we were not able to meet SLA for an operation by the client. So, we tried the same application with database connections using ADO.NET just for comparison. We analyzed our database operation performance and found out that for many queries, the performance went up by 300% and even more than that at times. This is a huge difference! After these results, we opted ADO.NET for the final version of an application.
Why does Dapper lag behind ADO.NET?
Dapper implements a lot of optimization recommendations of ADO.NET internally. When you are fetching a huge data structure, it performs a little slower because of the mappings it does between the data and the object model (custom POCO classes). Basically, Dapper is a data mapper, or you can say micro ORM, which internally uses ADO.NET only. So, if you can write good ADO.NET code, then it will always leave Dapper behind.
This is based on my experience of building huge database applications and in general, this is what happens. Dapper might perform very similar to ADO.NET in a few cases. So, I can conclude that ADO.NET is always a better choice if you can write an optimized query.
Conclusion
ADO.NET > Dapper > Entity Framework