XYplorer Beta Club

When moving/copying large numbers of files or folders, I see XY getting stuck because it's only using one CPU core. What should go relatively quickly instead looks like XY has crashed.

I would like to request that XY be able to use multiple CPU cores.

Oh yes! I'd like to second that wish. I've got a Quad Core system with 4GB of RAM and, while I appreciate that XY is light on resources, I'd also like to see it use more CPU/RAM if it means operations can be done quicker. This and pure 64-bit version are quite important wishes

How is it when you use explorer? Since XY uses shell for copy operations it should be the same as explorer.
From what I understand, XY will have its own copy operation sometime in future.

serendipity wrote:
How is it when you use explorer? Since XY uses shell for copy operations it should be the same as explorer.
From what I understand, XY will have its own copy operation sometime in future.

I have to admit, I am very reluctant about apps that use their own copy routines. Usually, they're faster because they're cutting corners on safety and verification, and that makes me very nervous.

Mesh wrote:

serendipity wrote:
How is it when you use explorer? Since XY uses shell for copy operations it should be the same as explorer.
From what I understand, XY will have its own copy operation sometime in future.

I have to admit, I am very reluctant about apps that use their own copy routines. Usually, they're faster because they're cutting corners on safety and verification, and that makes me very nervous.

I am sure Don will not write some copy function thats unsafe for users.

serendipity wrote:I am sure Don will not write some copy function thats unsafe for users.

I once encountered a situation when I was moving a file using WE and the moving process froze due to an unknown glitch. Once WE came back to life, I discovered that the file had not been moved and instead became corrupted. If XY's own functions will prevent that from happening then I'm in favour. Currently, I only see them as a workaround for the Vista 32-bit freezing problem. But that's off-topic...

...back on topic. As far as I know, no other file manager is multi-threaded so that will be a big plus in XY's column.

In my humble opinion, a file manager is not a kind of program that needs immediate multithread implementation.
In the case of copying/moving files, it uses the shell, and the OS uses U/DMA to copy files. The CPU load you may have seen is due to another OS routines involved in the process. XY, if frozen, is maybe because it waits for the shell copy process. I have to admit that WE does not freeze when copying files. Maybe the XY's copy routine that calls the shell should be in another thread so the main window doesn't freeze..

I'm not so sure that multiple threads is going to improve this case.

Sure, maybe XY will be more responsive (assuming the GUI is it's own thread, and a new one is spawned for actual tasks), but the move/copy probably wouldn't get done any sooner since the bottle-neck there is more likely the disk speed.

serendipity wrote:
I am sure Don will not write some copy function thats unsafe for users.

No developer ever intends to, but the price for bugs in a copy routine is quite severe.

TheQwerty wrote:I'm not so sure that multiple threads is going to improve this case.

Sure, maybe XY will be more responsive (assuming the GUI is it's own thread, and a new one is spawned for actual tasks), but the move/copy probably wouldn't get done any sooner since the bottle-neck there is more likely the disk speed.

I think it's also important to bear in mind that copy/move operations aren't the only ones that will be better with introduction of multi-threading, even if it's just in terms of responsiveness. Just looking at the roadmap, one can see that there are several forthcoming features that would not require manual intervention and will be running in the background. Things like refreshing of Search Results Caches (especially if linked to VFOs), CTBs, CEAs (especially if there are complex listeners), Folder Synchronisation (looking for dupes may be somehow involved in this). And that's just the roadmap. If XY is to remain light on resources' usage for those who do not run a powerful system while making use of the juice for those who have it there is a need for the application to be scalable and making it multi-threaded is a significant step in that direction, especially for high-end users, of whom there are quite a few (myself included).

I have to admit to dropping out to WE when I need to do any serious file copying/moving (between drives) just because it's a real drag having to wait for a multi GB file to finish before I can even browse another directory. I know making it multithreaded wouldn't make the copy happen any faster, and I'm not particularly fussed about that - it can take minutes and I wouldn't care - just so long as it's happening in the background and I can get back to other work.

lukescammell wrote:
I have to admit to dropping out to WE when I need to do any serious file copying/moving (between drives) just because it's a real drag having to wait for a multi GB file to finish before I can even browse another directory.

You don't have to wait for a copy/move to finish before you can browse. Just go into Config and enable Modeless in the Advanced tab.

Mesh wrote:You don't have to wait for a copy/move to finish before you can browse. Just go into Config and enable Modeless in the Advanced tab.

Nope.
It seems this option doesn't do the trick for me.
While the OS copy dialog is doing its job, if I click on XY's window, it gets Not Responding state until the copy is finished.
It can get really annoying if you often copy big files.
Hopefully I'm not one of those users.

tedy wrote:
Nope.
It seems this option doesn't do the trick for me.
While the OS copy dialog is doing its job, if I click on XY's window, it gets Not Responding state until the copy is finished.
It can get really annoying if you often copy big files.
Hopefully I'm not one of those users.

That's strange. I've never had a problem with this. I would say it's worth posting in the Bugs forum, because that's not how it should be behaving.

Mesh wrote:

tedy wrote:
Nope.
It seems this option doesn't do the trick for me.
While the OS copy dialog is doing its job, if I click on XY's window, it gets Not Responding state until the copy is finished.
It can get really annoying if you often copy big files.
Hopefully I'm not one of those users.

That's strange. I've never had a problem with this. I would say it's worth posting in the Bugs forum, because that's not how it should be behaving.

Not necessary. It's a known problem with Vista. XP does not have it, and Windows 7 neither.