Painfully slow (re-)generation of model with 100% cpu

Thread is closed for posting
3 posts, 1 answers
  1. Raoul
    Raoul avatar
    36 posts
    Member since:
    Apr 2012

    Posted 15 May 2015 Link to this post

    When opening the EntitiesModel.rlinq in my project it takes minutes (not seconds, minutes!) before the diagram is displayed in vs2013.

    The database -SQL 2012- is moderately complex with 176 user tables and 1314 constraints (PK/FK). At first I thought the high cpu utilization and slow (re-)generation occurred because the model was generated some open access versions earlier and updated with each subsequent release.

    Today I created a new project and recreated the model, but it is still extremely slow. When creating (or updating) from database the cpu rises to 100% and visual studio is non responsive. I've tried fluent, sperate files, xml or attributes in any possible combination but to no avail... Generation and updating are painfully slow. Just adding/changing columns to existing tables takes to much time updating the model from the database. Productivity grinds to a halt and I there's only the coffee machine to calm my frustrations at that point...

    So my question(s) are:
    - Could I break up the single model to smaller models, preserving FK relations "over the models". E.g. If tableA is modelOne and tableB is in modelTwo can I keep using "tableA.tableB" / "tableB.tableAs"?

    - Could it be a database issue? Tables are created straight forward with a single PK (Guid) and multiple FK's (also Guid). No indexes either.

    - Does anyone have suggestions on speeding up the (re-)generation of my model?

    It's just the model (re-)generation which is annoying. Other then that it does the job just fine.

     

     

  2.
  3. Answer
    Doroteya
    Admin
    Doroteya avatar
    498 posts

    Posted 20 May 2015 Link to this post

    Hi Raoul,

    I am sorry that you are experiencing issues.

    In general, we are aware that working with diagrams that contain a large number of classes results in high resource consumption. The cause for this, however, lies in DSL itself (the technology for building modelling tools in Visual Studio). Nevertheless, you can drastically improve the situation with the help of the next two approaches:

    Approach 1: Changing the mapping approach to Fluent (code-only) mapping
    The problem will permanently disappear if you re-generate the model with the help of the New Fluent Model wizard. It will produce for you all the necessary classes (persistent classes, metadatasource, context) and from that point on you can modify the model through the Fluent API. Additionally, any changes you do in the model can be persisted to the database with the help of the UpdateSchema method. With this approach you will not have an .rlinq in the project at all.

    Approach 2: Logically separating the diagram into multiple diagrams
    The multiple diagrams feature of Data Access allows you to separate the big diagram to smaller chucks, but to keep all of them in one .rlinq file. This way you preserve all the constraints and navigation properties. Additionally, when you open the .rlinq file, Visual Designer will initially draw only the default diagram. If you need to review any of the other diagrams, you can do it from Model Object Explorer.

    I hope this helps. Let us know if you need further information or assistance.



    Regards,
    Doroteya
    Telerik
     
    OpenAccess ORM is now Telerik Data Access. For more information on the new names, please, check out the Telerik Product Map.
     
  5. Raoul
    Raoul avatar
    36 posts
    Member since:
    Apr 2012

    Posted 22 May 2015 in reply to Doroteya Link to this post

    Doroteya said:


    Approach 2: Logically separating the diagram into multiple diagrams

    Thank you!

    Approach 2 did the trick.
    I've broke up the diagram in smaller logical pieces keeping the rlinq as a single file. This kept my references and now the individual diagrams are shown much faster.

     

Back to Top