Reply to topic

KDE applications file/directory copy methods

Xman
Registered Member
Posts
4
Karma
0
Dear all.

I have this issue since years but i didn't quite managed to ask about it.
Any KDE-based application (usually a file manager) that tries to copy large directories with many small files gets really slow.
This has proven true over the years for any KDE version on any distro, from the old Mandrake to Fedora to *buntus to Opensuse and even to FreeBSD which i played a little with some years ago.

Now, let me explain this better.
I wanted to back-up my data to another hdd (internal).
I reformatted everything in ext4 since i KNOW that ntfs is not terribly fast outside of windows (however it did not matter all that much in the end).
My system has a Phenom triple core at 2.5Ghz i think with 2Gb of RAM.

While copying the movie collection all was peachy. High transfer rates (100Mb/s) since these were Gb large files.

But i have this directory called sites which is a collection of websites i saved using a webspider years ago.
This has something like 700000 files and 300000 directories with small files like pictures, html, js and so on.
Wether i use Dolphin or Krusader or any other KDE based file manager i get these results:
- scanning of source directory - approx time 2 hours, cpu utilisation 100% on 1 core, cca 70% on the other 2;
- actual copying - cca. 14 hours - same cpu usage;
- inactivity after the actual copy - cca 2 hours with same cpu usage;
- end of copy.
The total system RAM usage was 1.7Gb.

This really bothered me so i wanted to try something more basic like rsync but without the checksumming so i actually did it with cp -au source destination.
The same directory was copied again with these results:
- no scanning of source directory, copy started immediately - finished in less than 2 hours, cpu usage was 90% fluctuating for one core and cca. 30% for the other two.
The total system RAM usage was 400Mb.

What is going on ?
I figure this is something in the base libraries or maybe even in Qt ?
But really, this is ancient tech (cp is around for how long ?) and i thought a desktop file manager might have figured it out already.
Even Windows seems to just wrap "cp" in the graphic stuff and gets blazingly fast (i know, it does not scan source to check if it fits the destination but i don't care about this one).

Please enlighten me on this one or direct me to a lower level in the stack (perhaps Qt ?) forum/list where i can ask these question and get some answers and possible solutions.
User avatar bcooksley
Administrator
Posts
18592
Karma
83
OS
KDE applications use KIO to copy files and folders. I believe the code which handles this is based in kdelibs, at least for local filesystems.
In terms of getting an answer as to the performance of this, I would suggest sending a mail to kde-devel@kde.org, particularly if you're familiar with C++/Qt and are interested in improving the performance.


System Settings and Device Actions KCM maintainer
Image
Xman
Registered Member
Posts
4
Karma
0
Thank you.

Of course it is KIO but KIO use internally Qt stuff which uses or not something else from the base libc, so i need someone who knows how things happen.

My c/c++/Qt skills are nonexistant.
Even so, i can see a good/bad architecture but only from what other people tell me (can't read code, well, can't understand it actually).

I will send a message to kde-devel if i don't find anything in a couple days.
User avatar bcooksley
Administrator
Posts
18592
Karma
83
OS
I've taken a quick look and can't see anything directly related to copying - just file reading and writing, so it is possible this is an unoptimised operation. It is possible this is handled at other parts of the stack though, so i'd suggest asking the developers.


System Settings and Device Actions KCM maintainer
Image

 
Reply to topic

Bookmarks



Who is online

Registered users: Alexa [Bot], apater, Baidu [Spider], bcooksley, Bing [Bot], eagleton, Exabot [Bot], Google [Bot], google01103, GreatEmerald, hmethorst, khsien, koriun, La Ninje, lazyit, Majestic-12 [Bot], SecretCode, Sentynel, Steve T, urgo, Yahoo [Bot]

cron