Version: (using KDE 4.1.2)
Installed from: Ubuntu Packages
I've made a simple test I want to share with you.
mkdir one ; cd one ; for p in `seq 1 500` ; do mkdir a$p ; cd a$p; for i in `seq 1 10` ; do touch b$i ; mkdir c$i ; done ; cd .. ; done ; cd .. ; cp -a one two
This way I create a directory named "one" containing 500 directories. Each directory has another 10 directories and 10 empty files.
Then I clone this structure to another directory called "two".
Dolphin takes up to 19" to delete the directory "one". Please notice that about 17" of that time is spent just counting files/directories.
Then I try the same with Nautilus with the directory "two", and it takes less than 3". On this case the files/directories counting is almost unnoticeable (it takes less than a second).
Why is Dolphin counting taking so long? The scroll bar seems to be accurate on both programs, but it takes ages to get the neccessary input on Dolphin.
Thanks for the detailed report, the issue has been fixed by David Faure already (see http://www.kdedevelopers.org/node/3683 for details) and is available in KDE 4.1.3 / KDE 4.2.
Thanks, but http://dot.kde.org/1223050704/ says this is already on 4.1.2. Are they wrong?
Hm, I don't know honestley speaking. Maybe David can comment on this (I've added him as CC to this report).
I'm reopening this until someone can confirm it's really fixed. This seems to be another different issue.
Yes, this case is a bit different from the one I fixed previously, because here there are a lot of subdirectories, which means a lot of ListJobs for listing them (about 5000 listjobs). Investigating this made me improve a few things that were slow with job handling (a QUrl bug, some slow connect statements, and some unnecessary object creations), but the global performance overall doesn't seem to have changed much. QUrl is said to be 3 times faster with Qt-4.5 so I'll re-evaluate this once we use 4.5. Meanwhile, I'd say this is the price to pay for network transparency, the generic way of listing dirs makes the local case slower, and even though I added shortcuts for local things in other areas (stat'ing and deleting), I don't think the code would be nice if the listing of subdirs was duplicated to special case local dirs.
And 5000 subdirs seems like a big enough case for 20 seconds to seem acceptable :)
I have the same problem here. I am running with KDE4.1.3. Deleting Qt4.4.3 source code itself takes me minutes to run... Is there any way that deleting files WHILE counting files and folders? It's just my humble opinion.
I can confirm this and honestly - this is bugging me for years.
It does not only affect deleting of dirs. Also copying of several small files is slower..
*** This bug has been confirmed by popular vote. ***
I can also confirm this, it takes a very long time to delete a directory with sub-directories and files it in. It is also very slow to empty the trash/wastebin.
KDE 4.2.0, Arch Linux w/KDEMod 64 bit
SVN commit 927652 by dfaure:
Speed up deletion of deep directories by speeding up the slow part of it: the recursive listing
- no need to stat() before opendir(), we can use the error codes from opendir to handle "it's a file" and "it doesn't exist"
- no need to stat() every file in this particular case of recursive-listing-for-deletion,
we just need to know if file/dir/symlink, which opendir tells us.
The testcase from bug 174144 (5000 subdirs) went from 20+ seconds to 13 seconds here.
Better but not perfect, since this testcase should ideally take about 3 seconds.
M +10 -36 kio/kio/deletejob.cpp
M +12 -8 kioslave/file/file.cpp
M +68 -54 kioslave/file/file_unix.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=927652
SVN commit 927756 by dfaure:
Implement recursive deletion inside kio_file. Brings down the 13-seconds testcase to 2 seconds,
although it kills progress information completely for the case of "deleting one directory with stuff in it".
M +3 -8 kio/kio/deletejob.cpp
M +9 -1 kio/tests/jobtest.cpp
M +31 -0 kioslave/file/file.cpp
M +3 -2 kioslave/file/file.h
M +1 -0 kioslave/file/file.protocol
M +2 -1 kioslave/file/file_unix.cpp
M +5 -3 kioslave/file/file_win.cpp
WebSVN link: http://websvn.kde.org/?view=rev&revision=927756
@David Faure : Sorry for asking here, but I could not post a comment on your blog entry.
Would it be possible to also add support for this to kio_fish?
Instead of doing all the stat'ing, just sending a "rm -rf" to the remote server?
Should I open a new bug report for this?
Yes please open a different bug report for kio_fish; the kio_fish author will have to look into how to implement recursive deletion.
Will the improvements made be present in 4.2.1? Just thinking 4.3 is quite a long way off to have this bug sticking around.
I haven't backported yet, better wait for possible regressions to pop their head. A bit of slowness is surely much better than bugs/crashes/regressions in a stable release....