Re: [gtkmm] TreeView performance

Tim Flechtner wrote:
> i use the 'standard' list store (which i would think would incur the 
> least cpu overhead).

I don't think so... The standard list store is optimized for flexibility, not
for speed. (At least it is in other libs -- I'm not yet that deep in gtkmm to
be sure here.) It allows you to store whatever objects you want, but this
requires intermediate object layers -- container objects and stuff --, so you
cannot avoid overhead. To optimize CPU usage, it's usually more efficient to
implement a model that directly accesses your data.

> would multi-threading help?  it seems to me like 
> whether it was one thread in a process or several, they would 
> collectively be making the same demands on the cpu?  slightly more in 
> the multi-threaded case beacause of the context switches?

The idea is to reduce the total number of notifications to the view. If you
get, as you said, new data about 500 times per second and every time put it
directly into the model, you get 500 view updates per second. _That_ certainly
eats a lot of CPU time. But if you let your app collect these 500 changes, put
them all at one time into your model and _then_ trigger the view notification,
you only get one view update in the same time.

I'd spontaneously do this collecting in a thread of its own, just to be sure
it doesn't jam the rest of the program, especially signal handling. But it's
just an idea, everything without guarantee. As I said, I'm pretty new to gtkmm
myself. I only had some experience with optimizing tree views in other libs.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]