views:

128

answers:

3

I've got an application which adds 10+ items to a treelist every second. This causing the control and UI to unresponsive and sometimes can't even paint it enough, also consumes a lot of CPU.

These new items coming from different threads so I can't use .BeginUpdate() unless I do some sort of local caching.

If I do BeginUpdate() and EndUpdate in fixed intervals then control stuck unpainted/blank between the intervals.

What's the best solution against this problem? Caching sounds stupid to me because in theory control got it's own caching anyway, so there should be a way for me to tell the control do not update but leave the control in the last painted state instead of something blank.

A: 

If you have multiple threads suppling the additions then they must be marshalled onto the control's owning thread anyway.

As such it is simple to implement a single batching mechanism post marshalling.

The control's caching is unlikely to be designed around your specific requirements (this is not normal behaviour for widget toolkits of this kind) so it is likely that you can do better with a cache specific to your load and responsiveness needs.

ShuggyCoUk
+3  A: 

Since the new Items come from different threads you already need Control.Invoke , you might as well batch that. So push your items in a Queue, and on the main thread poll that queue (using a Timer probably) and add a batch of Items in a BeginUpdate/EndUpdate block. The Timer interval will let you configure responsiveness. You will have to lock the queue but you no longer need Invoke.

Henk Holterman
A: 

It looks as though your issue is the responsiveness of the application rather than anything else. 10 items a second does not sound very intensive (unless they are very heavy items) therefore they shouldnt cause a problem.

I would guess that adding Application.DoEvents would make your application respond as you expect. It seems the issue is with processing windows messages in a timely fasion rather than the load that is being done.

You will need to invoke to the main thread to add the items to the control therefore there should be no problem with calling a DoEvents a few times a second as you go through. This wont be a massively efficient solution but I think it will address your lack of responsivness.

Tollo
I'm using invoke not doevents.
dr. evil
Yes, but my understanding of your problem was that the application is not responsive. My guess is that the issue is not load but ability to process messages. If you add DoEvents in, it is likely that the application will become responsive, irrespective of whether you use invoke or not.It seems strange that for only 10/second you have a non responsive app, therefore I'm guessing its not the cpu load at all but rather the processing time.
Tollo