Copy operation over slow network slows down Salamander

[Oliver S]

I'm not quite sure if this is already partly supported... while a slow copy operation over the network was taking place, I tried working with SS and it was possible - well, kind of. Actually it was so horribly slow that I couldn't really do anything useful, while the CPU wasn't loaded at all.

I guess that currently there's really only one main thread and you're taking care to pump the message queue every now and then, so it appears to be possible to continue using the GUI. Do you plan to implement real multi-threading anytime soon?

Thanks!
Oliver

[Jan Rysavy]

Each background (Copy/Move/Delete) operation runs in a separate thread.
You can use the Sysinternals Process Explorer to examine application's threads.

Back to your problem. Could you reproduce it with latest Servant Salamander 2.5 beta 10a?

[grymmjack]

I'm not quite sure if this is already partly supported... while a slow copy operation over the network was taking place, I tried working with SS and it was possible - well, kind of. Actually it was so horribly slow that I couldn't really do anything useful, while the CPU wasn't loaded at all.

I guess that currently there's really only one main thread and you're taking care to pump the message queue every now and then, so it appears to be possible to continue using the GUI. Do you plan to implement real multi-threading anytime soon?

Thanks!
Oliver

I would love this feature. Currently you can minimize or do other things within SS when you move/copy but not in archives or from archives, or when in ftp mode. It would be great if we could keep working in SS while doing ANY operations

[Oliver S]

I was using the beta you named when I saw this problem.

Maybe it's important that the target of the copy operation was an smb share on a system that's being accessed through VPN? So the throughput is naturally quite slow (not more than 15KB/s, I expect). This doesn't really explain why the application was so unresponsive, I guess - just thought it might give you a hint.

[Jan Rysavy]

Currently you can minimize or do other things within SS when you move/copy but not in archives or from archives, or when in ftp mode. It would be great if we could keep working in SS while doing ANY operations

Background operations for archives: ALTAP Roadmap.
The FTP plugin operations are already non-blocking and multithreaded.

[Jan Rysavy]

Maybe it's important that the target of the copy operation was an smb share on a system that's being accessed through VPN? So the throughput is naturally quite slow (not more than 15KB/s, I expect). This doesn't really explain why the application was so unresponsive, I guess - just thought it might give you a hint.

...while a slow copy operation over the network was taking place, I tried working with SS and it was possible - well, kind of. Actually it was so horribly slow that I couldn't really do anything useful, while the CPU wasn't loaded at all.

Could you make some test on this smb share?
Is Servant Salamander slow during both upload and download operations?
Is navigation in Options > Configuration dialog box slowed-down too?

[Jan Rysavy]

Moderator: Changed thread subject. Moved from Feature Requests.

[Oliver S]

Could you make some test on this smb share?
Is Servant Salamander slow during both upload and download operations?
Is navigation in Options > Configuration dialog box slowed-down too?

Okay, I think I know what the problem is. When working with the application while the copy process is running, file and directory information (or whatever) is apparently queried from the share directory again and again, depending on what exactly I do. For instance, if I have the share directory open in the right panel and a local directory in the left one, a delay occurs every time I try to do anything with the right panel... and sometimes when I don't really notice I did anything. Even just selecting a file in the list or navigating away from the original share directory is difficult because in involves several serious delays. On the other hand, if I try carefully to navigate only in the left hand (local) panel, things work fast and normal, as does the configuration dialog.

[Jan Rysavy]

Please try to turn off Options > Configuration > Drives > Network drives > Use automatic refresh.

Does it help prevent annoying refreshing?

[Oliver S]

Not bad, that works much better

Only one delay now, which is the time it takes to start a copy process that accesses a number of files on the remote share - no interaction possible during that time.

Good support here, I must say!

[Jan Rysavy]

You can set the Do not refresh on activation of Salamander option too.

Use the Left (Right) > Refresh command (Ctrl+F9 or Ctrl+R) to reload panel contents manually.

[Oliver S]

Yes, I saw that. That last problem I meant is just because Salamander needs to collect the information about the source files. A small info box is shown during that time, saying something about cancelling with Escape - obviously that process takes a while on the remote share and it doesn't seem possible to do anything while it's taking place.

[Jan Rysavy]

Yes, this initial part of each operation is managed by the main thread. Servant Salamander GUI is blocked, Reading directory tree message is displayed during this stage. It could be (theoretically) postponed to the separate thread, but it is a low priority for us (there are several problems related to this change).

[Oliver S]

Not much of a problem, as it's a one-time operation. Then again, for really large directories and/or slow connections, this takes really long. Maybe some status information would be nice?

[Jan Rysavy]

Do you mean some progress bar or remaining time estimation? Unfortunately, we cannot predict the depth of directory tree we are reading.

EDIT:
During this stage Servant Salamander is examining selected directories and prepares an internal script which will control following background operation.