Huge time difference observed when linq execution in Linqpad and VisualStudio Output window
A sample linq query to execute in Linqpad takes 1.039 sec without Dump() statement. With Dump() execution, it takes 1.137 sec.
The same linq query when executed in the application and checked in Visual Studio output window, it takes only 0.256 sec.
Note: query is executed on 2 tables with 10 & 25 records respectively.
With the time difference is so high, the linqpad time is non-reliable. Please advice how I can get more reliable time in linqpad.
The same linq query when executed in the application and checked in Visual Studio output window, it takes only 0.256 sec.
Note: query is executed on 2 tables with 10 & 25 records respectively.
With the time difference is so high, the linqpad time is non-reliable. Please advice how I can get more reliable time in linqpad.
Comments
Do you see the reason and solution for this issue ? If you need some more information from my end, let me know.
Could you please check my query and provide a solution or a better approach to verify execution timings.
I did similar test using your above sample code but by creating a wpf sample project.
I have a customer table with 155001 records.
In Visual studio, the execution time was 616 ms where as in Linqpad it took 3024 ms in first execution. In subsequent executions in linqpad, it took only 268, 272 sec.
There is a huge difference of 2408 ms. Please guide how can I get correct timings in linqpad.
Would you be able to create a simple Console project with the code above and compare the times keeping things as simple as possible.
In WPF project, I created a connection to DB using 'ADO.NET Entity Data Model' template and inlcuded the required tables to the created edmx file.
The C# code is same as you suggested above.
I created a console project and added the same C# code.
The execution time was 2171 ms (randomly I got 1969ms, 2042ms on subsequent running of console project).
Observation made : The Execution time in console project is higher than that in WPF project. Normaly, I was expecting console to be faster in execution. Why is this huge difference ?
Also, there is still difference (about +/-1000 ms) in execution time between console project and Linqpad. Please guide how this issue can be resolved.
With the information provided, do you see any reason for the issue ? I am using free version of Linqpad.
When you run an EF query in LINQPad, it creates a DLL with a type that subclasses your data context, then instantiates it in a process. Again, there are a number of factors that can impact cold startup time.
Cold startup is not normally the most important thing - for most real-world apps, it's the time taken to run subsequent queries.
Code:
var data = new MyEntities();
var sw = Stopwatch.StartNew ();
Console.WriteLine (data.Customers.Count());
sw.Stop ();
This time setup is equivalent to that in Linqpad, as in Linqpad I am executing only one query to get the time:
Customers.Count()
Since I am timing only linq query in project and Linqpad, their timings must be almost equal, but that is not the case.
My requirement : I need to write a linq query (from scratch) in Linqpad. To get a performant query, I need to check the execution time. Once the query is finalized, I copy the linq query to my application.
Since the time difference is too high, I cannot rely on linqpad execution time.
After copying the linq query to the solution, I have to check the execution time given by Visual Studio Output window. If the time is not acceptable, then again I need to review and modiy the query in linqpad. This is time consuming process.
Do you have any other approach for this problem.
Could you please reply to my above comment, regarding an alternative approach to my requirement.
If it's to tell you the real-world overhead of running Entity Framework queries in an application, then the cold-startup overhead does not matter. So you should execute the query twice in LINQPad, and record the time taken for the second execution. I think you'll find that that matches the time taken for the second execution in Visual Studio.