Preben Soeberg wrote:
One problem I can point at, is that mouse queue message handling takes a lot of time. Having a design with a few thousand nodes and leaving the puck on the tablet can easily use 100% CPU without getting any real work done.
I am not familiar with the renderer, but perhaps this could be sped up a lot by: 1. rate limiting GDK_MOTION_NOTIFY in emit_event (it's in sp-canvas.cpp if anyone wants to have a look). 2. Maintaining a 2D interval tree of object bboxes in SPDocument, so that sp_event_context_find_item, as well as the code that finds the item to emit the events on, is faster. 3. Optimize the nearestPoint routine (for example my node tool needs to call this on every motion event).
In any case, any slowness people might experience is not a result of bloat, but of a lack of optimizations or using suboptimal data structures (for example we are using a singly-linked list for selection contents, where we should be using a multi-indexed container with a list and a hash index, preferably via Boost.Multiindex). Therefore we are on the opposite end with regards to the Vista case :)
My 2 cents in the performance discussion: we should attempt to improve the startup time, as this is the most apparent metric of a "bloaty" feel. I wasn't able to identify any big bottlenecks with gprof, but adding some print statements with timing information at critical places might turn up something.
Regards, Krzysztof