实体框架和SQL Server Profiler

Question

I have some performance measuring issue between the EF query run through the web application and running the Profiler generated T-SQL directly into the SQL Query window .

Following is my EF query that executes through the web application:

IEnumerable<application> _entityList = context.applications
                    .Include(context.indb_generalInfo.EntitySet.Name)
                    .Include(context.setup_budget.EntitySet.Name)
                    .Include(context.setup_committee.EntitySet.Name)
                    .Include(context.setup_fund.EntitySet.Name)
                    .Include(context.setup_appStatus.EntitySet.Name)
                    .Include(context.appSancAdvices.EntitySet.Name)
                    .Where(e => e.indb_generalInfo != null);

                if (isIFL != null)
                    _entityList = _entityList.Where(e => e.app_isIFL == isIFL);

                int _entityCount = _entityList.Count(); // hits the database server at this line

While tracing the above EF Query in SQL Profiler it reveals that it took around 221'095 ms to execute. (The applications table having 30,000+, indb_generalInfo having 11,000+ and appSancAdvices having 30,000+ records).

However, when I copy the T-SQL from Profiler and run it directly from Query window it takes around 4'000 ms only.

Why is it so?

Answer 1

The venom in this query is in the first words: IEnumerable<application> . If you replace that by var (ie IQueryable ) the query will be translated into SQL up to and including the last Count() . This will take considerably less time, because the amount of transported data is reduced to almost nothing.

Further, as bobek already mentioned, you don't need the Include s as you're only counting context.applications items.

Apart from that, you will always notice overhead of using an ORM like Entity Framework.

Answer 2

That's because EF needs to translate your code into TSQL first which is costly as well. Look at this link here: http://peterkellner.net/2009/05/06/linq-to-sql-slow-performance-compilequery-critical/ It'll let you compile your LINQ and should help you with the speed. Also, do you really need that many tables for this query? Maybe you can think of a way to filter it out and only pull out what you need?

Answer 3

The EF definitely has a cost in terms of performance. But it also provides the flexibility to use storedprocs for complex TSQL. But in my opinion it should be your last resort.

Answer 4

in case you interested re performance and EF. http://msdn.microsoft.com/en-us/data/hh949853.aspx

However...

EF Query in SQL Profiler it reveals that it took around 221'095 ms to execute.

then..

copy the T-SQL from Profiler and run it directly from Query window

Where the SQL came from is irrelevant. Q1 took x millisecs. Based on SQL profiler info Exact same Query Q1' takes less based on SQL profiler. Which means the source of the SQL isnt the issue, it implies environmental issues are involved.

The most obvious explanation, SQL server has buffered many data pages and can much better serve the second identical request.