Yes, I do. If 90% of all the job is done by database itself, don't expect any ORM will significantly help you.
Now let's think what does this mean - to have a database eating 90% of operation time. First, I'd check if there are no any architectural or hardware problems.
- What kind of queries do you send? Are their plans efficient? Do you have enough RAM on database server to avoid frequent HDD seeks? If it's mainly computational load, may be it's a good idea to add more CPUs? Have you thought about storing transactional log on SSD? Anyway, I'd recommend you to find top 5-10 most "heavy" queries and think why they're so slow.
- If nothing related to #1 is found, likely, you must pay attention to various caching techniques. Almost any of them allows to significantly reduce the load on database server - of course, with some consequences. But such sites as Facebook and LiveJournal simply won't exist without them. If you know Yandex (Russian Google :) ), PCs in their search cluster simply keep (cache) all the data in memory. Think about this.
So main conclusion is: if your RDBMS handles 90% of job, likely, this isn't good. But I agree, in this case ORM performance is the last thing you should care about. As well as ASP.NET performance / caching, communication channels and so on. You have a single weak component, and thus it doesn't matter if other components are good or bad. So in this case you must care about it first, and then, if the issue will be resolved, switch to the next one.
Note that this problem isn't related just to ORM and database: it is related to everything. If you have 10Mbit LAN, likely, ORM is the last place you should look at. If there is mainly computational load on application server, but it is too slow to handle all the requests, forget about ORM. If your computer game spends 90% of time on AI, and you have a slooow CPU, forget about your HQ graphics card.
I believe many real-world applications imply there is high load on database server. On the other hand, if this happens, but it works, this is just acceptable! Normally no one worries about any of components in this case. On the other hand, if this is the same case, but the performance is critical, the first thing you'll think about is how to move some load out of the database. As I've mentioned, there are no tricks here, i.e. the ways are pretty standard. And when this is done, you'll start profiling your DAL (ORM), business layer and all the other components.
Finally, I want to give one more reason for ORM to be fast: if one ORM is 3 faster than another, and queries they run are relatively simple (OLTP), transactions on the first one will be 3 times shorter. But transaction duration is associated with maximal transaction ratio: the longer you keep them open, the loger you consume the resources of database server. But since they're limited, others will be waiting for them longer as well.
