Opened 13 years ago

Last modified 6 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 Changed 13 years ago by cybot_tm

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 Changed 13 years ago by Tim Kosse

Please try most recent FileZilla 3 beta.

comment:3 Changed 13 years ago by vanbroup

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 Changed 13 years ago by faucon

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 Changed 12 years ago by Alexander Schuch

Can you please try FileZilla 3 beta-8?

comment:6 Changed 12 years ago by faucon

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 Changed 12 years ago by Tim Kosse

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 Changed 12 years ago by faucon

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

comment:9 Changed 12 years ago by Alexander Schuch

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 Changed 12 years ago by faucon

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 Changed 12 years ago by Tim Kosse

Please try the coming 2007-05-19 nightly.

comment:12 Changed 12 years ago by faucon

I used the 2007-05-20 and the result is the same. Get slow after 30 seconds. CPU at 100%, etc.

comment:13 Changed 12 years ago by Tim Kosse

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

comment:14 Changed 12 years ago by faucon

Ubuntu 7.04 (GNU/Linux)

comment:15 Changed 12 years ago by Tim Kosse

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 Changed 12 years ago by Tim Kosse

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

comment:17 Changed 12 years ago by faucon

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

Note: See TracTickets for help on using tickets.