![]() ![]() #8 0x00007ffff597c6dc in KIO::CopyJobPrivate::sourceStated(KIO::UDSEntry const&, KUrl const&) (this=0xa5b4090, entry=., sourceUrl=.) at /home/kde-devel/kde/src/kde/kdelibs/kio/kio/copyjob.cpp:482 #6 0x00007ffff597dbd1 in KIO::CopyJobPrivate::statCurrentSrc() (this=0xa5b4090)Īt /home/kde-devel/kde/src/kde/kdelibs/kio/kio/copyjob.cpp:738 #5 0x00007ffff59d93b0 in KDirLister::cachedItemForUrl(KUrl const&) (url=.)Īt /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kdirlister.cpp:2785 #4 0x00007ffff59ccba1 in KDirListerCache::itemForUrl(KUrl const&) const (this=0xbeaca0, url=.)Īt /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kdirlister.cpp:782 #3 0x00007ffff59ccf9a in KDirListerCache::findByUrl(KDirLister const*, KUrl const&) const (this=0xbeaca0, lister=0x0, _u=.)Īt /home/kde-devel/kde/src/kde/kdelibs/kio/kio/kdirlister.cpp:836 This would provide O(log N) lookup without any additional memory requirements, but would require some overhead for sorting whenever items are inserted or modified. An alternative would be to sort the KFileItems in the list by their URLs. One could use a QHash to provide O(1) lookup for URLs, but this would require a lot of memory and CPU cycles in large directories. Looking at KDirListerCache::findByUrl shows that it scans the (unsorted) list of KFileItems until the URL is found, so the runtime has a quadratic dependence on the number of files that are copied, which is problematic if that number is very large. ![]() I usually get backtraces like the one below. I can confirm that copying lots of individual files is *extremely* slow and tried to investigate that with poor-man's-profiling. Just to be sure, do you copy a folder which contains lots of files, or do you copy the files individually? I.e., do you select a single (but very large) folder and copy it, or do you enter the folder, select all files and then copy them? Moreover, could you tell us the exact number of files, and, if they are not in one directory, roughly how they are distributed in the directory tree? I agree that "I'm copying a 15GB of thumbnails" is not a common case, but regardless whether it's a common case or not, there is clearly something broken in KDE (or Dolphin or KIO or XYZ component). I'm leaving this as "Grave" because this is something that shouldn't be happening in such a mature DE and because this bug is making my machine unusable (while copying files). The desktop should stay responsive and the file progress should be hitting the HDD's limits instead of hitting who-knows-what-bug in KDE which is making the progress slow. The desktop is laggy and the copy process is slow. Create a 15GB folder with subfolders and small files (20-40 kb each file) This is what 'lshw' says about it:Ĭonfiguration: created= 16:46:46 filesystem=ext4 lastmountpoint=/home modified= 12:58:29 mount.fstype=ext4 mount.options=rw,relatime,data=ordered mounted= 12:58:29 state=mountedġ. The HDD is a Western Digital WD Blue WD5000AAKS 500GB 16MB Cache SATA 3.0Gb/s 3.5". I'm on EXT4, and the drive isn't damaged, I can completely asure this (no errors in SMART, ran a few bad-sectors detectors liveCDs, everything is fine). The CPU usage in both cases is more or less the same, around 30% to 50%. ![]() Note that this doesn't happen with rsync. Even things as simple as moving the mouse pointer feels slow (the mouse pointer jumps from one location to another). rsync will take around 20 minutes to copy that amount of data, while KDE takes several hours (5-6, even 10).ī) the entire desktop (or maybe just plasma and all KDE-related stuff?) gets completely laggy/unreasonably slow. Where talking about a +20x difference in times, compared to rsync. The problem is that copying a 15GB folder with small files (thumbnails, ~20-40 kb each file) will:Ī) be ridiculously slow. Feel free to changed it to whatever component you think is better. I'm assigning this to Dolphin, but I'm not really sure if this should be assigned to Dolphin or KIO or any other component. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |