Opened 18 years ago
Last modified 11 years ago
#3112 closed Bug report
Faster delete of files
Reported by: | vanbroup | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | Other |
Keywords: | Cc: | vanbroup, cybot_tm, Tim Kosse, faucon, Alexander Schuch | |
Component version: | Operating system type: | ||
Operating system version: |
Description
Deleting a bulk of files (say 1000) takes a long time till you click a right mouse button in the remote file list or press the esc
key.
Change History (17)
comment:1 by , 18 years ago
comment:3 by , 18 years ago
I installed the beta 3.0.0.6 version but the problem is not solved.
Deleting a lot of files is now always small and a right click or esc
key does't make it faster anymore.
comment:4 by , 18 years ago
This is because (I think) there is the listing of all files while you are deleting.
This also occurs in the beta 6.
comment:6 by , 18 years ago
So... here is one test :
My complete folder of files from the gallery version 2 software witch have 8914 elements, and 77,5 Mio (Mb). Some subdirectory of course.
At first it is going blazing fast. After about 30 seconds, my cpu goes up, filezilla is using the most he can (80%), and the transfert rate goes down. There is some kind of bug in there.
So i'll use another folder...
337 files, 9Mb.
FileZilla 3 beta-8 : 247 sec.
FileZilla 3 beta-7 : 202 sec.
Same thing with the 30 seconds bug.
I think that the 30 seconds bug, is more likely the real problem here.
comment:7 by , 18 years ago
It could have something to do that after a couple of files the message log exceeds its line limit. Deleting line takes lot of CPU power it seems.
comment:8 by , 18 years ago
I can't see anywhere in the options to change that value so I could test that theory.
comment:9 by , 18 years ago
There is no way yet to change the size/length of the message log. However, as soon as FileZilla gets slower and the message log starts scrolling, you can right click into the message log and select "clear" in order to clear it. If FileZilla then gets fast again, it is the message log which slows it down. Can you test it and report back?
comment:10 by , 18 years ago
Your theory is good. When it get slow, I clear the message log and it is fast again. It took less then 60 seconds for the same directory. There is the bug.
comment:12 by , 18 years ago
I used the 2007-05-20 and the result is the same. Get slow after 30 seconds. CPU at 100%, etc.
comment:13 by , 18 years ago
This hasn't been mentioned before I think, which operating system are you using?
comment:15 by , 18 years ago
Ok, that explains it. My speedups have been for the Windows platform, which really had a performance issue with the log. However I do have some ideas to speed up the GTK version as well.
yes with all this files selected it is very slow - but even with no files selected it is somehow slow - possible you can suspend the file listing update when deleting large bunch of files ...