[PATCH/RFC] On the iconview and the speed of directory listing.

[David Faure]

On Sunday 25 May 2003 02:09, Maks Orlovich wrote:
> Hi...
> 
> If I apply the following simple patch to KIconView, and disable wrapping of 
> icon text, Konqueror is able to list a directory (on warm disk cache), with 
> 20,000 files[1] in about 3 seconds on my Celeron 950; w/o this or with 
> wrapping on it takes about 90 seconds[2] (where the time measurements are for 
> KonqKfmIconView::slotNewItems; which is obviously not all relevant time, but 
> the magnitude difference does seem to carry though; but this doesn't make 
> that dramatic a difference on smaller directories); I am not sure about the 
> reason for the dramatic difference. 
> ____________________________
> --- kiconview.cpp       4 Mar 2002 00:51:49 -0000       1.57
> +++ kiconview.cpp       25 May 2003 00:05:16 -0000
> @@ -361,7 +361,12 @@ void KIconViewItem::init()
>  {
>      m_wordWrap = 0L;
>      d = 0L;
> -    calcRect();
> +    //We only need to re-calculate the rectangle if we're wraping,
> +    //since otherwise QIconViewItem::init() would have
> +    //called QIconViewItem::calcRect() already. (Actually, it would skip it 
> if there
> +    //was no iconView(), too, but so do we, so it makes no difference)
Very verbose comment - "no iconview" never happens :)

> +    if ( iconView()->wordWrapIconText() )
> +       calcRect();
>  }

Looks good, obviously. I should have done that from the start.

> Now, I looked at our calcRect() implementation, and it seems there is no easy 
> way of improving it, as QIconView is not very friendly to overriding 
> calcRect():
> 1. The old one will get called in the QIconViewItem ctor anyway, as 
> KIconViewItem vtable wouldn't yet be active.

Right. Should we sent qt-bugs a patch that delays QIconViewItem::calcRect()?
Hmm, sounds a bit difficult, the layouting relies on it.

Another idea: we could create items without a parent view (passing 0 to the
QIconViewItem constructor), then calling insertItem() to insert it, then
calling calcRect() ?

> 2. The 3 separate set*Rect() calls all do a considerable amount of internal 
> manipulation.

Indeed. This calls for a single setAllRects()...

> Now, I am not sure of what to do WRT to the word wrap case at all. 
> kdelibs's word-wrap is certainly much nicer, but the difference is huge. 
> (If I drop our  calcRect() and paintItem() along with a then-redundant call to 
> calcRect() in KIconViewItem::init(),  slotNewItems takes about 5 seconds; 
> total CPU time for Konq at startup in that dir is reported as 10 seconds by 
> top). Perhaps if I can figure out why the non-wrapped case is changed so much 
> I'll be able to offer a good option; but I figure it's worth getting this 
> info out...

Ah, so the worse isn't the additional calcRect() call, but the actual word-wrap
implementation, KWordWrap::formatText()? 

-- 
David Faure -- faure at kde.org, dfaure at klaralvdalens-datakonsult.se
Qt/KDE/KOffice developer
Klarälvdalens Datakonsult AB, Platform-independent software solutions