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

[Maks Orlovich]

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)
+    if ( iconView()->wordWrapIconText() )
+       calcRect();
 }

 KIconViewItem::~KIconViewItem()
____________________________
The only reason I didn't commit it yet is that this makes triggering  
KDirLister crashes on very large directories pretty much unavoidable - don't 
ask me why. I would also appreciate if someone could confirm this 
independently (see my footnote [2] for a good reason). 

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.
2. The 3 separate set*Rect() calls all do a considerable amount of internal 
manipulation.

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...


Comments, suggestions, etc., welcome and encouraged.

Thanks,
Maks.
------------------
[1] The following is an easy way of generating a directory this large:

#!/usr/bin/env ruby

0.upto 20000 do |val|
        fname = "test"<<val.to_s
        file = File.open(fname,"w+");
        file.close
end

(Or the equivalent in your favorite programming language)

[2] Which means I somehow screwed up the performance assesment on the 
dirfilter patch, or Qt3.2 makes such a big difference.