Slow local list view in directory with many files

[Andrew]

The local list view pane for local files in a directory with many files (not sure exactly how many), or perhaps large files, is prohibitively slow on my Windows 7 machines. It brings Filezilla to a crawling halt.

[Tim Kosse]

Most likely explanation is that you have a broken virus scanner that scans everything before it allows FileZilla to merely query file attributes.

Please uninstall all virus scanners and try again.

[Brian K. White]

I have seen this problem for a long time as well, both on WinXP and 7.

I dismiss your dismissal that I am an ignorant user who doesn't know how to manage his own PC and thus suffers any number of speed or reliability problems.

This kind of bug report shouldn't be about "me" but since you make the accusation, the only way to address that is to trot out all the gory details no one really cares about, about the details of my particular hardware and software setup.
Then you tell me where the newbie mistake is that means filezilla is blame-free for how sucky the local directory panel is.

Currently I have a new Sony Vaio VPCZ1 1290X
It has:
Core i7 M620 3.2 Ghz, dual core, 4 threads
4G DDR3 PC3-8500, 2x2G dual channel symmetric
2x64G Toshiba SATA2 SSD's, writeback cache enabled, ina raid0, (not a typo, striping-only , all speed)

Currently running in full performance mode where all parts are running at full power & full possible speed, verified by CUI-Z for the cpu & ram, and Intel Rapid Storage raid control panel for the raid array and individual drives.

The OS is Win7 x86_64

The OS is configured completely for performance. No Aero, no Indexing, No animations or transitions, Looks like Win95. Heck even the display depth is reduced to 16 bit.
Scheduling set to favor programs vs services.

The machine is idle.

The Windows performance Index thingie shows 7.4 for disk data transfer rate, 6.9 for processor, 5.9 for memory. (on a scale that only even goes from 1.0 to 7.9!)

The only malware/antivirus even installed at all is Microsoft Security Essentials.
Scheduled scan is disabled, real time scan is enabled, and yes all options are enabled in the real-time scan. (Also DEP is enabled in the OS) I could MAYBE see disabling the heuristics option (labeled as behavior monitoring) but these days really that's not even safe any more. But as we'll see below this is a non-issue anyways. Whether MSE sucks or not doesn't even matter.

OK so all aspects of the hardware are more than reasonably fast, and the OS and software load are at least claimed to be more than reasonably light weight and optimized with the possible exception that maybe Microsoft Security Essentials is somehow a bad antivirus program for a Microsoft OS. Hey as a Linux/FreeBSD/Solaris/SCO Unix admin I'm the FIRST to hate M$ and completely ready to believe that. Or that having all options in the realtime scan enabled is too aggressive and will have exactly this kind of result completely expected. OK I'll buy that too.

Only one problem. These statements aren't made in a vacuum and as it happens I can simply observe things that invalidate them as arguments.

First, the reason I even use MSE is because it's the fastest and most trouble-free antivirus I've ever used. I haven't had it break anything else and I do use some krufty old legacy database and app software that hasn't been substantially updated since the days of Win2K, which other antivirus (pick almost any, Norton, McAfee, AVG, TrendMicro) does break and MSE doesn't. If MSE sucks, it's only by being less secure because it's not by being slower.

But that's still subjective...

The final datum that can't be dismissed is simply that other software, specificaly and notably other open source software, does not suffer the same lag, or any lag at all, doing the same job at the same time on the same machine in the same directory with the same files in it. That's it really. End of story right there from that one fact.

Even doing things multiple times and in reverse order to negate any caching effects, filezilla consistently hangs for several seconds at a time, the entire fz app, window decorations disappear, the OS offers a popup to kill the non-responding app etc..., just by trying to display and scroll through my Downloads directory. Yet, neither OpenOffice, nor Gimp, nor Code::Blocks, nor Notepad++ sufferes any hang at all displaying and scrolling through the same directory. switching the order of which app tries it first to try to expose or negate disk buffer caching effects, still the other apps are always instantaneous, and FZ always hangs.

It's true that if I disable the antivirus the lags in FZ go away.
That doesn't address the fact that somehow all the other apps can display a directory panel dialog without any delay under the same exact onus.

Disabling the antivirus, or even most of it's individual features, is a completely unacceptable answer, especially in a file-transfer utility which specifically deals with the Downloads folder more often than any other, and all that THAT should imply.

Since the other apps can do what looks like exactly the same job, they display the file list, including icons and sizes and timestamps etc, and they are open source apps, not M$ apps that may be making use of undocumented internal hacks that the rest of us can't use, that means it's pretty irrefutable that FZ is either doing something, or failing to do something, to cause the hangs, not that the user has misconfigured their PC, or they have a slow PC, or their OS is full of junk, or their antivirus is broken or inefficient.

"Uninstall all virus scanners an try again." Amazing.
Hmm, enjoy speedy virus-free computers for over 5 years without ever having to reinstall, or enjoy FileZilla? Hmm... dang that's a tough one.

Oh go ahead and re-close the bug of course. With the kind of attitude expressed by that kind of response to the reported problem I hardly expect a little thing like more reports or better evidence to make a difference. I re-open it only as a knowingly pointless gesture merely so that I can at least say that I did. I can't complain if I didn't at least try to report through the supposed proper channels and didn't at least do basic homework to eliminate all the obvious possible causes or affectors of a given symptom.

I would much rather have appreciated seeing a simple honest answer like "We don't know why it's so slow when others are so fast." or "It's so slow because we do extra work on every file every time it's encountered and we're not changing it." I might not like being told "Too bad, it's staying slow." but that's still better than being told "You must be a diptard with 3 concurrent antiviruses active at the same time and your local hard drive must be a usb stick accessed via network share over half duplex 10baseT hub so of course it's slow."

[matthewdixon]

I have this problem too. Fast desktop PC, well configured. Viewing or reviewing a directory that contains a lot of files slow FZ to a crawl. As a previous user mentioned, other programs don't have it. It is an effective hang for some 10-20 seconds.

[alflanaga]

I see it on a download directory with numerous large files. Hypothesis: it's so eager to put an icon beside the file name, it scans the whole file looking for an embedded icon? Nah, that's crazy.

[Andrew]

4 years later, same exact problem (quad core 17, 6gb RAM, etc)

There seems to be some consensus that it's the antivirus at work here. But how do other programs with list views speedily show you all elements in the list without freezing up?

[alflanaga]

Update: I can verify problem related to McAfee Antivirus. This product often "goes nuts" when you do a full scan of a file, and of course downloaded files probably get extra scrutiny. I'm still not clear on why just listing the directory would cause problems, however.

[BayAreaEagle]

If you turn off Security Essentials and the local file browsing is normal, then very likely there is a conflict between the Security Essentials and the filezilla.

My suggestion is first make sure that you did install the latest version of Security Essentials and the file zilla version which is 3.8.0. for the file zilla version, please check that you are downloading from the authentic resource https://filezilla-project.org/download.php?type=client, not from other third parties.

Second, you need to do defragmentation do your c drive, over the time, the files are saved into small segment of the file system, it will make retrieving files cost long time. I used to do the file defragmentation every 3 months. I find that browsing file have 30% faster. you can learn how to do it by visit this ​http://windows.microsoft.com/en-us/windows/improve-performance-defragmenting-hard-disk#1TC=windows-7

Third, you can consider to buy a paid antivirus software instead of using the free Security Essentials. paid antivirus software provides tech support and usually they are more robust. The full price of paid antivirus software may look high, you can save some money by using a coupon, currently McAfee antivirus have 50% off, you can get the McAfee promotion from ​McAfee Promotion and Norton has $40 off Norton 360 now, you can get it from ​Norton Coupons

Hoping you can resolve the issue soon.

[blindpet]

This bug persists even in latest version 3.9.0.2 (over 400 files in the listing). Using tight vnc viewer to transfer files from the same directory does not result in any lag. I am running win 8.1 with no anti-virus besides the built-in.

[pinkman]

Replying to Andrew:

The local list view pane for local files in a directory with many files (not sure exactly how many), or perhaps large files, is prohibitively slow on my Windows 7 machines. It brings Filezilla to a crawling halt.

2018 year, and it's still didn't fixed. It's impossible to use filezilla with this directory navigation's bug. Uninstall

[Tim Kosse]

You have a broken virus scanner that scans everything before it allows FileZilla to merely query file attributes.

Please uninstall all virus scanners and try again.

[Andrew]

This is literally the only application I've ever encountered on Windows that exhibits this behavior.

The sad thing is that Tim will not change his mid or revisit this issue after 9 years of the same issue.

This is not enough of a reason to move to another FTP client, but it sure is sad.

[Andrew]

PS - even if you are not interested in fixing the problem, why are you closing the ticket? This is a legitimate problem and you are doing a disservice to the FileZilla project and open source community with your off the wall suggestion to uninstall a core piece of every Windows installation - an anti-virus.

This ticket should remain opened, regardless if you refuse to acknowledge Filezilla's list view pane implementation sucks raw eggs and needs improvement.

[pinkman]

Replying to Tim Kosse:

You have a broken virus scanner that scans everything before it allows FileZilla to merely query file attributes.

Please uninstall all virus scanners and try again.

I disabled all scanners (including windows's default), it's doesn't help. And yes, such bug exists only with filezilla (even all other's ftp clients works fine)

[Tim Kosse]

I'm not arguing with you and have already told you why I am right.

[Andrew]

Tim, by telling us you are right, you are arguing and disagreeing with us. Our suggestion would be to fix the list view implementation so it operates like every other application's listview on Windows (with and without an AV) - i.e. it loads quickly and without the delay there is in FileZilla - and it does not require a patently unreasonably workaround that nobody in their right mind would use on Windows (uninstall their AV).

I am not not bothering to re-open since you choose to deny this, but for the record, I hope someone looks at this and resolves the root problem.

They can start here (if I was a C/++ expert I would as well)

LocalListView.h
LocalListView.cpp

[Tim Kosse]

You have it backwards, you are disagreeing with me without providing proof for your claims.

[Andrew]

The proof is in dozens of comments above where the behavior has been replicated over a period of 9 years on multiple Windows machines.

[Brian K. White]

Problem still exists.

[blindpet]

@Tim what would it cost to get this fixed, I was going to donate to FileZilla but this bug prevents me from justifying such behavior!

[Brian K. White]

How long before he just starts deleting users who insist on reporting this BUG which EXISTS?

[Robert Macdonald]

I, too, have been experiencing this issue for a long time. I keep hoping an update will make it go away but so far it hasn't happened. I don't have a broken AV scanner.

I keep a long list of large install scripts in the local directory. Start up is very, very slow. Refreshes of the list view are jerky and subject to 10 and 15 second delays as the list is resorted.