none
Extremely slow performance using Code-First with Entity Framework 4.1 release

    Question

  • Our company is developing a new application, which has a somewhat large business data object at its core.  We decided to try out Entity Framework with code first to abstract the database from the application, but things have gone awry.  The business object is composed of approximately 60 classes, and in total around 600 properties; however, it is a tree structure and no crossover/backtracking pointers are present.

    Our test was to add a single, uninitialized instance of the class to the database.  Using DbContext.Add on our data structure took 8 minutes on my development machine.  Is this the expected performance of an object this size?  Is there a list of common problems that causes poor performance with Entity Framework?

    Some more data points: There are 27 elements in the first level under the root of the business object.  With 3 elements present (the rest commented out), the time to add is 4.5 seconds.  With 5 elements present, it is 11.8 seconds.  With 8 elements present, it is 1 minute 12.5 seconds.  Obviously, the size of these elements varies significantly, but these does seem to indicate a systematic problem of some sort.
    • Edited by Dave dps Monday, August 8, 2011 10:06 PM Added more data points.
    Monday, August 8, 2011 9:59 PM

Answers

  • We figured out there was a problem with how we were implementing our data structure.  One of the category classes was subscribing to the PropertyChanged events of its children.  This was just some experimental code someone had put in to play with a logging feature.  We only discovered this issue as we were trying to migrate to NHibernate, and it eventually crashed (which was good! -- it let us know something was wrong, and we could trace it).  EF didn't give us any information about there being a problem, other than it didn't finish for far too long.
    Saturday, August 20, 2011 12:35 PM

All replies

  • Hi dave,

    I am using code first too and i cant see such strange performance issues. I am initializing my database too with dbcontext and add operations. Its also a hierachical structure with appartments, rooms and room depending tables.. 

    I create around 5 structures per second. A structure means a complete object with filled depending entites and so on. 

     things to consider when initializing a database, from my point of view are..

    1) use a granularity that makes sense 

    dont add 10.000 entites and call Commit(). Split it into groups of 20 or 50 depending on your object complexity.

    2) dont use one and the same db context. use a context per block.

    if you create 10.000 entites it will flood your memory if you dont split your initialization into blocks..

    3) disable autodetect changes  

    before adding any objects, disable with context.Configuration.AutoDetectChangesEnabled = false;

    Just make sure you enalbe it before you want to commit your changes.

    hope that helps a bit..

     

    greetings

    holger

    Tuesday, August 9, 2011 8:48 AM
  • Hi Dave,

    Welcome!

    Thanks for @Holger's reply. 

    To tell you truth, I haven't used EF in a big project. There is a Power tool generating pre-complied views to improve the performance. The more performance consideration is here: http://social.technet.microsoft.com/wiki/contents/articles/3901.aspx

    Hope it helps.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, August 9, 2011 11:42 AM
    Moderator
  • Hi Holger,  

    Thanks for your reply.  This test was for a single object, not 10,000.  And we did also turn tracking changes off.  Are there any other possibilities?

    Tuesday, August 9, 2011 2:20 PM
  • Hi Alan, 

    Thank you for your reply as well.  I will try to work with that pre-compiled views approach today and get back to you.

    Tuesday, August 9, 2011 2:21 PM
  • Hi dave,

    maybe you could try to split the savechanges of your huge object? 60 classes sounds like 60 tables and 60 navigation property and relations. if i understood you correctly. If you are able to split the object, try to build it not with one SaveChanges on the context. Create the depending objects, save them and put the FK into the object that holds the reference and so on.

    Sorry i dont have another idea. i ve never seen such a big busines object ;)

    holger

    Tuesday, August 9, 2011 9:55 PM
  • Hi,

    I am writing to check the status of the issue on your side.  Would you mind letting us know the result of the suggestions?

    If you need further assistance, please feel free to let me know.   I will be more than happy to be of assistance.

    Have a nice day.


    Alan Chen[MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Saturday, August 20, 2011 9:18 AM
    Moderator
  • We figured out there was a problem with how we were implementing our data structure.  One of the category classes was subscribing to the PropertyChanged events of its children.  This was just some experimental code someone had put in to play with a logging feature.  We only discovered this issue as we were trying to migrate to NHibernate, and it eventually crashed (which was good! -- it let us know something was wrong, and we could trace it).  EF didn't give us any information about there being a problem, other than it didn't finish for far too long.
    Saturday, August 20, 2011 12:35 PM