Performance and memory issues for CSLA

Performance and memory issues for CSLA

Old forum URL:

TF Zheng posted on Monday, June 04, 2012



Our configuration system below using CSLA, together with Entity Framework and SQL 2008, has some performance and memory management issues.


Our system:

Buildings (150 properties/building)---> Floors (17 properties/floor)-----àRooms (34 properties/room)


We tried one Model below:

  Buildings (EditableRootList) ---àFloors(EditableChildList) -----à Rooms(EditableChildList)


For one building with total: 2511 objects, and 85334 properties in three tables:

It took:
      24 seconds to create/initialize and populate in DB.

      14 seconds for a complete update.

      4.5 seconds to delete all.


Our goal is to do 100 buildings. So, the performance and memory management will be critical for us, as far as initialization, updating, binding, etc.

We plan to replace EditableRootList  to DynamicRootList  for Buildings and Floors.


Any other good approach for such system? Such as paging, etc….



All suggestions are welcome...Thanks ahead...


RockfordLhotka replied on Monday, June 04, 2012

You have the basic structure of your DataPortal_XYZ methods correct I assume? Things like turning off list changed events, using BypassPropertyChecks, etc. Missing those basic things can cause substantial performance issues.

Assuming you have all that correct, the next step is to isolate whether the issue is in:

Those are all potential performance bottlenecks.

sergeyb replied on Tuesday, June 05, 2012

In addition to what Rocky says, you might want to consider getting away from root list and instead have just one building as the root with a search screen to allow users to select a single building.  YOu have to be carefull with EF when populating 2500 objects in a single swoop.  I would get aways from lazy loading as this may results in excessive number of queries, event though each one is fast, but if you fire 2000 of them, there is no way you could execute all that in less then 10 seconds probably.  I am guessing this is your #1 problem.  You can confirm easily enoguh with an SQL profiler.

Copyright (c) Marimer LLC