Performance on network drives

[Orson]

I've tried every suggestion that I've seen posted in this forum in order to speed up browsing performance for network drives. (That is, accessed over a LAN although defined with a letter.) This is an important issue because most of the time I have to work on network drives, not my local C: drive. Compared with other file managers, XY has slower performance when I select a new folder on a network drive.

Our net drives are running on UNIX servers -- and I wonder if *that* has anything to do with the delay I notice when going to a new folder on one of these drives -- not to mention the 10-second wait when I access one of these drives after not using XY for an hour or so.

Any suggestions are appreciated.

Orson

[admin]

Compared with other file managers, XY has slower performance when I select a new folder on a network drive.

Could it -- again -- be the "resolve-whether-there-are-any-subfolders" issue? Many file managers, including Explorer, do not perform the time-costy check whether folders listed in tree have any subfolders or not; instead they simply put the "+" icon in front of them, *assuming* that there might be subfolders. XYplorer is different here: it does the check. Now, the more new (new to the tree) folders you list in the tree, and the more of them have *no* subfolders (in this case the check takes the longest time!), and the more of them contain a large number of files: the longer the check lasts.
Now, when you say "I select a new folder" what exactly do you do? Click a caption in tree? Click a "+" icon in tree? Double-click a folder in list? Select a favorite? Use the address bar? Use the catalog?

[lukescammell]

Regarding the "resolve-whether-there-are-any-subfolders" issue, could we not have this happen in the background (or have it as an option) on network drives?

This would allow XY to remain snappy, but still provide the correct information ASAP no?

[phatmankerr]

Know this has been discussed in the past, but I would definately agree with Luke.

I have demonstrated XY to a number of VERY impressed users (mainly network admins - see the problem) until we get to opening Network Drives with numerous folders at which point the delay gets in the way of an otherwise spotless bit of software.

[Orson]

Donald,

In reply, I usually have been selecting a folder by clicking an entry in the catalog, or by clicking a tab previously set up. I rarely use the tree for navigation thanks to the catalog and tabs.

I do appreciate the value of accurately displaying whether a folder has subfolders or not, by the way. I wish it didn't take so long to find that out, and I think the suggestions for doing this in the background or as an option might make sense, while providing the "snappy performance" that people appreciate.

I also notice that after displaying a folder with subfolders on a network drive once, XY lets me move among the folders without much delay. But if I don't use XY for, say, an hour or so, a similar delay sometimes occurs when I return to my network drive. I wonder if the info is cached (by XY?) for awhile, but after a certain duration the software says in effect, "I better check this again, it's been too long to trust my cache."

[admin]

I also notice that after displaying a folder with subfolders on a network drive once, XY lets me move among the folders without much delay. But if I don't use XY for, say, an hour or so, a similar delay sometimes occurs when I return to my network drive. I wonder if the info is cached (by XY?) for awhile, but after a certain duration the software says in effect, "I better check this again, it's been too long to trust my cache."

This looks a lot like a cache, but XY does not cache nothing here. So it is your OS that is not trusting its own cache.

Conc. subfolders: okay, I will for now just add an option to work as other file managers do: on a network drive always assume there are subfolders. Then we know more about the nature of the issue.
Maybe the problem lies somewhere else. Because, since you say you tried every tip available, I'm sure you have "Expand destination node in tree" turned OFF, and if indeed turned off then the subfolder check is not happening so it can not be the cause of the delay...

I curious and willing to solve the bloody network delay issue that's haunting me since years... (mad destination)

[admin]

Orson, check out whether it's more snappy now.

[surrender]

I am experiencing atleast 4 times faster access times on my network. .

[JML13]

Code: Select all

    * Experimentally, on network drives (UNC or mapped) freshly
      displayed tree folders are not checked for any contained
      subfolders anymore, but it is assumed that subfolders exist. In
      other words: the "+" icon is set unconditionally. This strategy,
      which is common among file managers, will speed up network
      browsing considerably.
      This new behavior is not yet configurable. Just testing... 

Very nice.
Browsing using tree view is faster.
But browsing using list view is still awful (not slower, but maybe not faster) : up to 4 or even 5 seconds to open a folder and see its files and subfolders.

[lukescammell]

Hmm, yes, the tree is basically where I'd expect it, though I still think the background tree checking would be slick, perhaps the [+] could be faded/greyed out or something to start with, then disappear or turn black depending on the outcome?

However, as I do most of my navigation using the list view (mainly just up and down a couple of levels), this hasn't sped up and now almost feels slower since the tree sped up.

[Gandolf]

Code: Select all

    * Experimentally, on network drives (UNC or mapped) freshly
      displayed tree folders are not checked for any contained
      subfolders anymore, but it is assumed that subfolders exist. In
      other words: the "+" icon is set unconditionally. This strategy,
      which is common among file managers, will speed up network
      browsing considerably.
      This new behavior is not yet configurable. Just testing... 

Speed is Fantastic!!! Can we PLEASE have that on the local drives. I can now log the same directory on the network computer faster than I can log it on the local machine (large number of sub-directories only containing files - my old problem).

[phatmankerr]

I am with JML13 here tree browsing is far quicker (:D ) however listview still takes muchos time to appear.

This must be something specific to the background work XY is doing (as other third party File Managers are still much faster on Network Drives).

But none of them are a patch on XY re. functionality and general usability so XY wins as usual ( ) - would just be nice to have fast listview and treeview though (on Network Drives). No speed issues on local unless there are a lot of .exe or .ico files and even MSPlorer can chug a bit then.

Cheers

[admin]

This must be something specific to the background work XY is doing ....

background work? There is none (none that I knew of )...

I'd really like to know what's going on here. I'm pretty sure I'm using the same calls for browsing as everybody else, and I know how to use them the fastest way possible.
Is it something with the network connection? Do I have to log on as a process to get special speed rights? Any idea is appreciated...

[Orson]

I just installed the new beta. Yes, network drive performance is *much* faster.

Orson

[jacky]

Just a FYI, with the latest beta speed is indeed quite faster on network (I use UNC paths) ! Allthough honestly it used to be quite fast for me already (never actually compared with other file manager, cause speeds were good I didn't feel any need to ) and I liked to have the expandable-state right

Obviously I do have auto-refresh enabled but not on network locations, and use generic icons only on network locations. (and no icon overlays either)