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.


  • What sort of LINQ query is it? Is it a LINQ-to-objects query or are you using LINQ to SQL or Entity Framework?
  • I am using Entity Framework.
  • Are you using the same connection in LINQPad? IOW, from "Add connection", are you choosing the Entity Framework driver and pointing LINQPad to your data context assembly?
  • Hi

    Do you see the reason and solution for this issue ? If you need some more information from my end, let me know.
  • Hi Joe

    Could you please check my query and provide a solution or a better approach to verify execution timings.
  • Does the 1.04 second time refer to the time for the first execution, or subsequent executions? (If you hit F5 again, it's normally a lot quicker).
  • edited November 2018
    For the first execution with a simple data context, I get around 1.2 seconds with both LINQPad and Visual Studio. To do the timing in Visual Studio, I'm creating a Console project with a Main method as follows:
    static void Main (string [] args)
        var sw = Stopwatch.StartNew ();
        var data = new MyEntities();
        Console.WriteLine (data.Customers.Count());
        sw.Stop ();
        Console.WriteLine ("Done " + sw.ElapsedMilliseconds);
    For subsequent runs (making changes to the query in LINQPad and hitting F5 again), it takes around 20ms.
  • edited November 2018

    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.
  • Does that include the time taken to dump the output? How are you measuring the time for your WPF project?

    Would you be able to create a simple Console project with the code above and compare the times keeping things as simple as possible.
  • The above time does not include Dump execution.
    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.

  • Hi

    With the information provided, do you see any reason for the issue ? I am using free version of Linqpad.
  • I don't know why your WPF project executes faster the your Console project. How are you timing it? You need to start the stopwatch the moment you double-click on the executable. There might also be issues relating to native image generation or other factors that are not obvious from a distance.

    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.
  • In the WPF and Console projects, I have started the stopwatch just before the Linq query statement, and stopped immediately after the linq statement.

    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:

    Since I am timing only linq query in project and Linqpad, their timings must be almost equal, but that is not the case.
  • I have started the stopwatch just before the Linq query statement, and stopped immediately after the linq statement.
    Then it's not a fair comparison. A lot of the cold-startup overhead is *before* that point.
  • Do you mean that when linq query is executed for the first time in linqpad, the execution time includes cold-startup overhead part ?
  • Yes, that is true with regard the cold startup overhead for the APIs that you use (such as Entity Framework).
  • If this is the case, the execution time is not helpful to me.

    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.
  • Hi Joe

    Could you please reply to my above comment, regarding an alternative approach to my requirement.
  • What is the purpose of timing the queries?

    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.
Sign In or Register to comment.