[PATCH] Speed up iconView's setIcons 2x...

[Maks Orlovich]

Carsten Pfeiffer wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> On Tuesday 13 August 2002 23:51, Maks Orlovich wrote:
> 
>> This is in fact mostly spent KonqKfmIconView::slotNewItems( const
>> KFileItemList& entries ) and suggests that my original patch is probably
>> not the best way of addressing it.. What happens here is that the
>> directory lister cache recognizes the familiar directory, and dumps all
>> of the files in it immediately to the icon view; so the view spends its
>> time processing all the items; and then updating the icons for them
>> before returning to the event loop.. I am thus not sure of what the
>> proper way of fixing this is -- anyone else?
> 
> What you could do is remove m_itemDict and use KFileItem::setExtraData()
> (I wanted to do this long ago). With a large directory, the 43 buckets
> dictionary looks a bit helpless.

<snip nice optimizations suggestions that'd likely not help that much due to 
bottlenecks being apparently in different spots>...

I've just profiled this, and in fact, what takes time (around 500ms of the 
600-800 cited) is basically the work done by the KIconViewItem and 
QIconViewItem's ctor -- or rather the calcRect() methods there. What's 
horrible, is basically what happens is the following:

When KDirLister hits in the cache, as in the setup, 
The icon view item is created with iconSize not yet set; its gets to 
KIconViewItem, which first constructs base... The base calls 
QIconViewItem's calcRect, since the vtable for KIconViewItem isn't 
constructed yet... Then KIconViewItem's ctor calls its own calcRect, 
re-layouting [Optimization sidenote: when called from ctor with wordwrap 
off, it shouldn't call own calcRect, since that would b eforwarded to 
QIconViewItem again -- but that's not the setup here]. This seems to takes 
about 600-700ms, based on my profiles...

Then, when we change the iconSize, every icon's calcRect is called again 
when the icon size is changed (twice, in fact, w/o my initial patch). 

What's pretty bad is that I can't see any way to avoid wasting clock cycles 
on the QIconViewItem's calcRect -- the only way to avoid doing that seems 
to be to pass 0 for the parent; but I don't see any way of repating the 
IconViewItem if that is done... 

If the cached DirLister output is somehow delayed we don't waste time 
layouting with size-0 icons, however, and then relayouting every single one 
(and in current CVS, repainting at 0,0...) -- with delaying the files from 
the dir lister cache a bit  (with my previous patch still in place) about  
500 ms of KIconViewItem::calcRect's seems to be saved going through the 
back-to-home sequence.., but I wouldn't take that number 100% certianly 
since I can't justic this one out on parer (.. in the evening)

Suggestions?

Thanks,
Maksim..