LINQ/Performance Test RRS feed

  • Question

  • Hi.

    I am currently working on a new WPF project and like to use an ORM for my DataAccess.

    The first ORM that came up was naturally the Entity Framework (EF), while reading into the topic.

    I read here and there that the performance of EF isnt so great compared to other solutions, tough accoring to the EF 5.0 Release Information some performance issued should have been adressed.

    After some further investigation I have come accross the following site: which looked like a nice comparision site. The sad thing about this site is that it was last updated in 2010, so it wasnt really an uptodate comparision.

    The good part about this website is that the testing solution is opensource and free to download, so after some testing with the old solution.

    I gave it a try to update the libaries one after the other and removed some orm tools for now, to make the upgrade easier for me in the first place. So if you download the files, you will find that there are OpenAccess by Telerik, EF with the "old" API and EF with the new API (DbContext) and the raw SQLClient usage being tested.

    Now to the question round:

    1.) Do you believe that this test is anything good or just a waste of my and your time?

    2.) Looking at the results the EF fails to keep up with the performance of OA and with pure SQLClient its not even close, is the test doing something wrong or is it a true fact that EF still lacks performance compared to others?

    3.) Comparing the new and "old" API, the old API often has an higher performance, so should I stick with the "old" API?

    4.) During the test I have noticed that the inherited classes in the EDMX "ActiveProducts" and "DiscountedProducts" wont get generated by the T4 template as an public property inside the DbContext class, so those two lines where missing:

    public DbSet<ActiveProduct> ActiveProducts { get; set; }
    public DbSet<DiscontinuedProduct> DiscontinuedProducts { get; set; }

    Is that a bug or went something wrong at my end?

    5.) If the test isnt very friendly to EF and it could be done more efficient with a higher result in this test, I would like to hear about those tweaks from you.

    Here the download links:

    (An excel containing the result with charts, for better comparison)

    (The solution folder inside a RAR)

    In the solution you can read the "Readme.txt" to get information on how to build/test and stuff, all will be linked to the homepage since i just changed the libaries and did almost no other changes.

    Just modified the Output.txt file a bit to make it easier for me to generate the excel file.

    When you hit start the "Run.bat" 2 command windows gona pop up, and will do some rather long work when its done they gona disappear and the Output.txt will be done. You can than fill the XLS file with the newly done data by copy and paste in the correct tables.

    Hope to get some opinions on this matter.

    Thanks in advance.

    Friday, July 12, 2013 2:21 PM

All replies

  • Hi Rand.Random,

    It is true that SQL Client and Entity SQL will run faster than LINQ to Entities.

    DbContext is a lightweight version of ObjectContext. Although DbContext LINQ query spends more time than ObjectContext LINQ query, DbContext API might be easier to use. I think you can choose the API depending on your requirements.

    The ActiveProducts and DiscontinuedProduct are derived from Product class. The base class will be generated as an abstract class and a DbSet will be generated in the context.

    You may have a look at EF performance considerations:

    EF inheritance strategy:

    Best regards,

    Chester Hong
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help

    Tuesday, July 16, 2013 4:29 PM
  • Thanks for the answer.

    Sadly you didnt really state your opinion on the provided test and only spoke on a very general point of view.

    @ I think you can choose the API depending on your requirements.:

    I know its possible to change the API I am using but reading the official comments of microsoft, when I am new into this matter I should stick with the new API, but in some cases there is a huge performance difference which I cannot really explain to myself why this is the case.

    For example a simple Update command can be done with DbContextAPI with a performance of

    1718 operations a second and the "old" API

    3074 operations a second.

    In my opinion thats quite the difference, thats why the question above:

    5.) If the test isnt very friendly to EF and it could be done more efficient with a higher result in this test, I would like to hear about those tweaks from you.

    @ ActiveProducts, DiscontinuedProducts:

    If its normal that there arent public DbSet properties for those two, how would a Linq query look like to get them?


    One of the reason I dont really understand why I should stick to the new API, because the whole thing about compiled queries rock and you should use them isnt relevant to the DBContextAPI because you cant declare a compiled query and it should "AutoCompile" them.

    Wednesday, July 17, 2013 8:22 AM