Slow performance listing directory via SFTP

Hi,
Windows 10.0.22621
WinSCP 6.3.3
Latency from client to server (Ubuntu OpenSSH_8.9p1) is around 150 ms
I have a peculiar situation that my remote data directory which I am listing via SFTP consists of 40 k (thousand) files. Because of this high number WinSCP performs visibly slower than other programs I tried.

1. WinSCP listing directory 73 seconds
   
2. FileZilla 23 seconds
   
3. lftp started as command line in the WSL2 10 seconds
   

I like WinSCP interface and would prefer to stick with it but I am looking for any ways to optimise the waiting time. Till now the only option I tried was to untick 'optimize connection buffer size' but it made no difference.
Thanks in advance for any suggestion.

Please post verbose logs from all three.

Hi Martin,
Attaching logs, my apologies I did not attach them from the beginning.

I thought that maybe logs collected via wireshark could bring some additional ideas. Attached.
one file is from winscp run, another one filezilla

Thanks. I do not see anything in the logs that would explain the difference. Though FileZilla log is unfortunately not very detailed. I'll check the Wireshark captures later. Meanwhile, can you get me WinSCP log from scripting using ls command?
https://winscp.net/eng/docs/guide_automation
https://winscp.net/eng/docs/scriptcommand_ls

I've noticed the cursor is flickering (between loading & normal state) when listing remote dir. Why is that? Could it be that WinSCP is wasting small amount of time for every file it lists?

In your logs the actual filenames entered to the log on the client side is:
12:12:08.815
to
12:12:09.549

That is under 1 second. It doesn't take long to just list whole strings.

SSH_FXP_OPENDIR, SSH_FXP_READDIR, etc is what's taking time.
eg...
That is pushing towards 3 minutes.

The interaction with the SSH server that is taking time. Although, I don't know how well the UI responds to listing 40k files and I don't see that expressed in the logs.

A rough estimate is at 90 char per filename is a list of nearly 4MB in size possibly to split apart into filename, size, type, etc. That too can take time in order to display it into the UI.

There's various possibilities for the 3 applications to be of different speed. Multi threading ability, connection stuff, UI response speed, sorting/parse/split code (or whatever), possibly settings, and possibly more.

In theory, 73 seconds / 3 threads is 24 seconds and 73 / 8 is 9 seconds. That closely matches the numbers of the other 2 clients that it could potentially be multi threading related. 8 threads would need a minimum of 4 cores with 2 threads each core if its multi threading.

It's possible too for multi connections, but I didn't look at that with your logs to see if the server connection time is similar or cut down. Otherwise, it would be a weird coincidence.