Performance impact of adding all table columns when generating domain classes

Thread is closed for posting
2 posts, 0 answers
  1. Anwar
    Anwar avatar
    14 posts
    Member since:
    Oct 2012

    Posted 29 Oct 2014 Link to this post

    I am a newcomer to Telerik Data Access, so sorry if this question has already been asked. When generating domain classes from my database tables, I usually select by default all table columns, which are then mapped to class properties. Some of the tables have lots of columns (in the order of 100+). I was wondering if this has a performance impact when using Telerik Data Access? In most cases I am accessing 2-3 properties in the generated classes.


  2. Kaloyan Nikolov
    Kaloyan Nikolov avatar
    118 posts

    Posted 30 Oct 2014 Link to this post

    Hello Anwar,

    That is very reasonable question. 

    Usually all properties except the navigational properties are part of the default fetch group which means than when you retrieve an entity from the DB all of the domain class' properties will result in a column in the select statement.

    This could lead to the following implications:
    1. If you have nvarchar(max) columns that are not needed they will be retrieved from the DB and as SQL server stores them separately from the other data in the table this could slow down the select statement
    2. When you have a wider result set this means more data and more time for network transfer from the server to the client. 
    3. Telerik Data Access retrieved all data for all properties but only the accessed properties lead to actual value materialization, so it is not expected to have significant performance impact in case you have a lot more properties than the needed. 
    4. Bigger entities consume more memory and thus the GC will have more work to free it. Under heavy load this could lead to serious performance problems. In some edge cases your application can be more than 90% busy with garbage collection.
    5. In case you use the Second Level cache then you will fill you memory with a lot useless information.

    In conclusion I can suggest you as best practice always to use the minimal needed properties as this can decrease the chance of bigger issues in the future. 

    Kaloyan Nikolov
    OpenAccess ORM is now Telerik Data Access. For more information on the new names, please, check out the Telerik Product Map.
Back to Top