Skip navigation.
KDE Developer's Journals

32 times faster deleting your home directory

dfaure's picture

Yes, KDE-4.2 will be 32 times faster deleting a large number of files compared to KDE-4.1!

I was looking at the highest-voted bugs last Monday (yes, voting _is_ useful in bugzilla, some people weren't sure about that), and bug 43356 (260 votes) was about konqueror taking too much time deleting a large number of files (in kde-3.0, but still true in 4.1).

I first made the KIO job itself 25 times faster for local files, but then it turned out that the KIO job was anyway "only" taking 35 seconds, out of the 8 minutes that konqueror-4.1 took for deleting 5000 times. The other 7 minutes and a half were spent updating the itemview, removing rows one row at a time. Ooops.

After making KDirLister emit a new itemsDeleted() signal with all items, and KDirModel processing this in a more clever way, the view is now told about the 5000 removed rows in one call, and deleting 5000 files with konqueror-trunk (or dolphin, same code) now takes only 15 seconds. That's 32 times faster.

Conclusions: Bugzilla rocks (and users report useful issues, we as developers never test enough of these large-datasets cases). Qt model/view rocks (there was no way to optimize this that much in Qt3). But, there are too many bug reports for a lifetime of bugfixing, unfortunately.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
tstaerk's picture

svn revision numbers

On bugs.kde.org, David says the relevant changes are r862165 and r861889, have a look at
http://websvn.kde.org/?view=rev&revision=862165 and http://websvn.kde.org/?view=rev&revision=861889

dfaure's picture

svn.kde.org down temporarily

Another few hours until it comes back, apparently.

http://news.opensuse.org/2008/10/10/power-outage-in-area-where-most-opensuse-servers-are-located

tstaerk's picture

can you paste the revision...

... then I can maybe do the same to kio_fish which is as well reported to be very slow.

dfaure's picture

Re: can you paste the revision...

As you can see, most of the fixes where in KIO, and therefore apply to all kioslaves automatically. If kio_fish is still slow, then one has to profile it to find out why.

dajomu's picture

digikam

Great to hear about these optimization of codes.
Now, what about having a look at digikam? It takes a long time to update the images when browsing a folder with many photos. Picasa do not have this problem at all.

dfaure's picture

Re: digikam

Sorry I have enough bugs to fix in konqueror/kio/kioslaves/kdeui/libkonq/dolphin/etc already. For digikam, please report a bug on http://bugs.kde.org and/or investigate where the problem comes from.

sandsmark's picture

you rock!

you forgot one thing from your conclusions: You developers rock! Laughing out loud

theriddle's picture

Sweet!

Great to see more optimized code. Instant on become more realistic every time people do things like this Eye-wink.

pascal_a's picture

Loving performance

Performance improvements like these are awesome!
I've used rm many times because I had a feeling that Konqueror/dolphin were taking way to long to do it. Now, it seems, I don't have to do that anymore Smiling
Thanks a lot!

Best regards
Pascal

mxttie's picture

same here. thanks!

same here.

thanks!

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.