Opened 17 years ago

Last modified 10 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 cybot_tm, 17 years ago

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 ...

comment:2 by Tim Kosse, 17 years ago

Please try most recent FileZilla 3 beta.

comment:3 by vanbroup, 17 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 faucon, 17 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:5 by Alexander Schuch, 17 years ago

Can you please try FileZilla 3 beta-8?

comment:6 by faucon, 17 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 Tim Kosse, 17 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 faucon, 17 years ago

I can't see anywhere in the options to change that value so I could test that theory.

comment:9 by Alexander Schuch, 17 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 faucon, 17 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:11 by Tim Kosse, 17 years ago

Please try the coming 2007-05-19 nightly.

comment:12 by faucon, 17 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 Tim Kosse, 17 years ago

This hasn't been mentioned before I think, which operating system are you using?

comment:14 by faucon, 17 years ago

Ubuntu 7.04 (GNU/Linux)

comment:15 by Tim Kosse, 17 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.

comment:16 by Tim Kosse, 17 years ago

Should be fixed, please try the coming 2007-05-23 nightly.

comment:17 by faucon, 17 years ago

Good call, it took 64 seconds. I think this can be closed.

Note: See TracTickets for help on using tickets.