I have followed the “Don’t Optimize Prematurely” mantra and coded up my WCF Service using Entity Framework.
However, I profiled the performance and Entity Framework is too slow. (My app processes 2 messages in about 1.2 seconds, where the (legacy) app that I am re-writing does 5-6 messages in the same time. (The legacy app calls sprocs for its DB Access.)
My profiling points to Entity Framework taking the bulk of the time per message.
So, what are my options?
-
Are there better ORMs out there?
(Something that just supports normal reading and writing of objects and does it fast..) -
Is there a way to make Entity Framework faster?
(Note: when I say faster I mean over the long run, not the first call. (The first call is slow (15 seconds for a message), but that is not a problem. I just need it to be fast for the rest of the messages.) -
Some mysterious 3rd option that will help me get more speed out of my service.
NOTE: Most of my DB interactions are Create and Update. I do very very little selecting and deleting.
You should start by profiling the SQL commands actually issued by the Entity Framework. Depending on your configuration (POCO, Self-Tracking entities) there is a lot room for optimizations. You can debug the SQL commands (which shouldn’t differ between debug and release mode) using the
ObjectSet<T>.ToTraceString()method. If you encounter a query that requires further optimization you can use some projections to give EF more information about what you trying to accomplish.Example:
Could be replaced with:
I just typed that out of my head, so this isn’t exactly how it would be executed, but EF actually does some nice optimizations if you tell it everything you know about the query (in this case, that we will need the category-names). But this isn’t like eager-loading (db.Products.Include(“Categories”)) because projections can further reduce the amount of data to load.