GNOME Bugzilla – Bug 76325
Moving hundreds of images exceptionally slow in Nautilus for Gnome2
Last modified: 2005-09-10 20:35:57 UTC
This should be easily reproduced: 1. Find two large image-directories. Preferably ones that haven't been fully thumbnailed yet. 2. Drag and drop a large bunch of files from one dir to another. It will take around a second for EACH file, even though they are on the same filesystem. Doing the same with mv will take approx. 1 second for the whole operation. What is wrong? It seems Nautilus tries to move each file and thumbnail them as they are copied. Instead it should of course just finish the entire moving process and put generic icons on the images and try to thumbnail them when it is finished moving. Besides, if you are moving thumbnailed images, shouldn't the thumbnails be moved as well?
*** Bug 76638 has been marked as a duplicate of this bug. ***
*** Bug 48487 has been marked as a duplicate of this bug. ***
*** Bug 46707 has been marked as a duplicate of this bug. ***
*** Bug 45243 has been marked as a duplicate of this bug. ***
*** Bug 81905 has been marked as a duplicate of this bug. ***
Want to take a look, jacob?
is this still a problem? the thumbnailing code had some significant bugs fixed since you reported this. what type of machine do you have (processor, memory)?
Well, moving mostly goes ok.. though still 1/5 of the speed of "mv". Deleting is worse. Moving to trash is about the same as a normal move, but deleting is painfully slow. Using about a second per file. "rm" does the entire bunch (about 40-50 files) in just a few seconds. It seems that there is still some redundant thumbnailing occuring. The images are replaced with the "waiting to be thumbnailed"-icon before they are deleted. My computer should be plenty fast: Athlon 800 256MB SDRAM NVidia GeForce 2 GTS One of the crappy, but fast recent IBM-drives.
Well, copying of /all/ files is slower than cp. That isn't image specific. Don't know about rm-ing.
This is still happening for me. Moving lots of images (500+) seems to move near-instantly an arbitrary number of images (sometimes 100, sometimes 400), and then slow down to one image every 3-4 seconds.
alex g, do you think this is from thumbnailing starting up on the destination? is the performance much worse for images vs. other files?
If we're looking at moving 100+ images before things slow down, I'm going to punt this. Dave, please add your thoughts before we kiss it goodbye, though. :)
The thoughts we just discussed are: Things seem to be copying fairly quickly for us at around 100 images. Orph was saying that during copying 500 images, things start slowing down a lot, jacob thinks this might be due to the thumbnailer kicking in. Jacob suggested freezing and thawing the thumbnailer during copy operations. As for moving thumbnails with images, there might be an easy way to schedule related copy operations, since the directory copy code (we think) schedules copying of the metafile when you copy a directory (but we might be wrong).
This seems to happen rather irratically with me currently. Sometimes moving 200 images is dog slow, sometimes moving 400 happens fairly fast. Seems to me there is just _too_ much complexity, and unknown factors in the process. You have to think about thumbnailing, moving, possibly moving thumbnailing, queuing, etc.. putting all kinds of thumbnailing on hold until the move process is completed sounds like a really good idea. There is also a lot of blocking going on when managing images, and it is probably related.
Still seeing this in Nautilus 2.2. It's not as bad but thumbnailing is still really messy when moving files. I don't see why a file should be re-thumbnailed when it is moved. Also the thing where a file turns to a default icon before disapearing looks really messy.
The same thing happens while removing (shift+del) lots of files in a large directory, I just tried to delete +400 files (.zip, so no thumbnails) in a directory containing +1000, after the first 180 or so, it slowed down to one file per sec.
*** Bug 167855 has been marked as a duplicate of this bug. ***
Marking this as duplicate of bug 304184, since the latter contains more information and patches.
*** This bug has been marked as a duplicate of 304184 ***