a critical performance issue.

a critical performance issue.

Old forum URL: forums.lhotka.net/forums/t/9311.aspx


keni_nan posted on Sunday, August 01, 2010

hello,

 when i do a performance test on CSLA , I found that there two points('ExtendedBindingList`1::OnAddEventHooks'   and ' BindableBase::add_PropertyChanged') spend the most of time . 

 

how can i handle this case?

 

 

thanks!

RockfordLhotka replied on Sunday, August 01, 2010

The most common performance issue when loading huge lists of child objects is event-related, but not really in those methods.

The common error is when people forget to set RaiseListChangedEvents to false before loading the list with data. That causes a lot of entirely useless events to be raised and handled, which slows down the load process (sometimes a lot).

So make sure you are setting RLCE to false, and then true after the load is complete.

keni_nan replied on Monday, August 02, 2010

hello Rock:

  I have set the property 'RaiseListChangedEvents' to false when loading the list. but i found 'AddEventHooks(OnAddEventHooks)' is invoked by 'LoadPropertyValue'; and 'PropertyChanged' is invoked yet.

 

thanks!

RockfordLhotka replied on Monday, August 02, 2010

RLCE just stops the list events from being raised, that's true.

There is no mechanism to stop PropertyChanged from being raised. Normally that's unimportant.

I suspect you are seeing the ChildChanged eventing implementation - that's the reason PropertyChanged is handled, so it is possible to cascade ChildChanged events up the object graph.

You must be loading many, many thousands of objects to see any perf impact though... Like 10's of thousands.

Either that, or something else is going on - perhaps you have a parent object that is handling ChildChanged, and something is being triggered there as each child is added?

detritus replied on Monday, November 29, 2010

I know this is rather old post but I think it still applies.

I see the same behaviour when I do a load test on the web site and OnAddEventHooks method is calculated as more costly than the db call (with compiled L2S). I'm not adding 10's of thousands items to ROLs but it's a load test thus the ROL.AddRange gets called many times (same number of times with the db calls).

Anyway, can anybody tell me what will I lose if I just disable these in ReadOnlyListBase (with an empty overrides)? More to the point, do we actually need these events in readonly lists (except may be in Silverlight)?

Thanks,

Sinan

RockfordLhotka replied on Monday, November 29, 2010

The big thing is to make sure you've turned off event handling (RaiseListChangedEvents = false) before doing any persistence of a list object.

What you'll lose if you don't call OnAddEventHooks is pretty obvious if you look at the code. You'll lose:

  1. Busy change notification
  2. Unhandled async exception notification
  3. PropertyChange notification (when child objects change)
  4. Child changed notification

If you do no async work and aren't using Silverlight or the async data portal, 1 and 2 won't matter.

If your objects are read-only then 3 and 4 won't matter.

If your objects are editable (read-write) then 3 and 4 matter quite a lot, since without them data binding won't work right.

detritus replied on Wednesday, December 01, 2010

Yes, I especially mentioned I'm thinking overriding those in no-async work and only in ReadOnlyListBase (inherited class in the app).

I've created a test to see what is the performance of the OnAddEventHooks call compared to db call and JSON conversion (with Newtonsoft lib)  and it shows that OnAddEventHooks is more expensive than the both if the item count is bigger than 100.

Then I created another test to see performance of the OnAddEventHooks call with different item counts (no db call or anything) and suprisingly I don't see any performance problem with it even testing with 1.000.000 items.

In short, I think I don't know enough about testing to see what the cause of the problem, I'm not sure if it lies with my application (or test project) code or with OnAddEventHook.

Copyright (c) Marimer LLC