Welcome to our world! Yes, we have seen this too. In terms of measuring it, we wrote MvcMiniProfiler such that it could wrap the standard db connection/command/reader etc (since ADO.NET is fairly decorator-friendly); so we can then measure the LINQ overhead via:
using(MiniProfiler.Current.Step("Getting awesome data")) {
var data = {your query that materializes data, i.e. ToList() etc }
}
then MvcMiniProfiler will show you the time etc of "Getting awesome data", along with the time spent in the SQL queries etc.
We found there was often a very big gap, even when using ExecuteQuery<T>(sql, args)
, which (along with some CPU activity probing) let us to strongly suspect that materialization was the culprit (in particular when running at high usage; we could see, for example, a 4ms query taking 80+ms due to overheads - so 76ms lost to LINQ). So then we wrote dapper-dot-net, which does an awesome job of slashing the materialization cost. A 4ms query takes 4ms again.
As an example:

the cols are (I've only included 2 rows, so the headings are missing):
step name | time in this step (ms) | offset from start (ms) | sql | time in sql (ms)
As you can see, it took 1.3ms to run the sql, and 1.8ms for the step, so 0.5ms overheads. The "1 sql" is actually a hyperlink to the sql (with parameters/values) that was executed. And you can run it 24x7in production without pain (....we do).