I've been working on sorting out some graphics files, mostly filing them away in different directories. I'll highlight a number of files and drag them to the destination directory in the folder tree. Both source and target in this case are on the same drive of a network data store. The graphical pile of files is assembled and moved along with the cursor without much trouble, but when the cursor crosses over to the folder tree, things start to grind to a halt.
Various potential targets that I've briefly passed over with the cursor get highlighted and stay that way long after I've moved past them. Once the cursor has settled on the intended target, it sometimes takes 15 seconds or more for DOpus to highlight the proper folder and display its name in the floating tool tip so I can be sure it knows where I really intend to put the files. Needless to say, these delays are annoying.
In an effort to figure out why it's taking so long, I did some searching here and found reference to a utility called FileMon. A quick Google check lead me to Microsoft where I found FileMon has been replaced by ProcessMonitor. I downloaded and installed it.
One thing that struck me immediately was the incredible number of accesses to registry data from practically every running process. It's no wonder a system feels sluggish when the registry grows beyond a few MB.
Related specifically to DOpus, I noticed an massive number of reads of the same 64 bytes from c:\windows\csc\00000001. In the neighborhood of 100 times a second when I was moving some files. I have no idea if this is a direct read or something Windows is doing behind the scenes. If the former, it looks like more than 50% of the system I/O calls could be eliminated with a simple 64-byte buffer. It does seem to be only during network accesses, but since that's the basic issue here...
Using ProcessMonitor really hasn't gotten me any closer to figuring out why there are the annoyingly long pauses and short freeze-ups when trying to select a drop target on the folder tree. It has made me wonder how my system functions at all with the vast number of file accesses that are going on for even the simplest of operations. (My world time clock is the source for a flurry of activity every second.)
So, I guess I'm still left with the question, why the pauses and mini-freeze-ups when choosing a target on the folder tree? And is there anything that can be done to eliminate this?
Firstly, do you see the same slow down in Explorer when you do the same action?
When you drag over the tree (or in fact over anything) Opus has to determine whether the item you are over can accept a drop. The tree is built using the shell API so this involves binding to the target folder and querying for its IDropTarget interface. And unfortunately, Windows being Windows, when you do this on a network folder, it tends to be rather slow.
I would have expected Explorer to be the same though, so if it's not it's probably something that should be looked into.
I think Process Monitor and similar tools have the tendency to be misleading - there is an immense amount of background activity that goes on in any normal Windows system, most of which does not impact performance at all. Certainly the read of the same 64 bytes from the same file over and over again would be cached by the file system and wouldn't actually be hitting the disk. To get any usable information out of Process Monitor you really need to define the filters to exclude this sort of constant background stuff, which can take quite a while as there is so much of it.
Have you considered abandoning the tree and using a dual file display for this? I think that dragging over network folders in the second file display as opposed to the tree should be a lot quicker.
DOpus has replaced Explorer, which I haven't used in ages. I have no idea if it suffers the same slowdowns.
I can say that avoiding the folder tree, as you suggested, completely eliminated the slowdowns.
While on one level I can understand the "Windows sucks" explanation, on another I observe vastly better performance when doing the same operation but avoiding the tree and I have to wonder if, perhaps, it would not have been a superior design decision to roll your own folder tree and avoid the shell API if that's the source of the problem.
As to the impact of reading the same 64 bytes over and over, I understand it isn't actually going to the disk for each of those, but it clearly is executing a lot of code that could be avoided. I don't know enough about Windows internals to know if a cache hit on a disk read results in the program being suspended while waiting for a response. Given that it was logged by ProcMon, I'm guessing it does.
I cut my teeth coding in the days when every byte and every CPU cycle mattered. I've spent more hours than I care to remember writing assembly code because Fortran wasn't fast enough. Perhaps the attitude I developed about avoiding system calls if at all possible simply don't apply anymore.
If you get a chance to try Explorer I'd be interested to know if you find the same thing.
I'll have a look and see if there's a better way we can do it. Unfortunately the tree really does have to be built (at least partially) using the shell, because that's the only way to get the Desktop -> My Computer -> C: type structure that people will expect. However we could be a little "smarter" and not call the shell when dragging over network folders, for instance.
On my system (Windows XP SP-2), concerning some tree operations the Explorer is much faster than DOpus. If you enable "Show ZIP files and other archives in Folder Tree", even simply opening directories with many subdirectories/files needs quite a time - even when there's no archive involved. PowerDesk for example (sorry for mentioning it... ) has a similar function, and the tree is lightning fast.
Maybe things are processed in a different order? DOpus seems to process the files first, while other file managers' first priority seems to be displaying the tree.
I got explorer to come up and gave it a try. I'm not seeing any hesitation at all from Explorer. Network drive, local drive, they all respond the same. And this test was done with the wireless connection being taxed near to the extreme by another process, which was not the case when I tried this with DOpus yesterday. Then the network traffic was very light.
I just double-checked with DOpus and I'm seeing the same hesitation and laggard behavior. There was even a bit of another behavior I've seen in the past -- the dreaded international "not" symbol. I selected about 100 files in one directory and dragged them over the tree folder. As soon as I started dragging the cursor turned to the circle with a slash and when I moved over the tree folder there was no reaction at all. (No changing of highlighted target directory.) I then selected six files from the same directory and got the same response, though the cursor turned from the slashed circle back to a pointer within about five seconds. Drop targets were still painfully slow to respond.
It's clear DOpus is doing something Explorer is not and is taking its sweet time doing it. I should mention this is nothing new. I saw the same thing with DO8. It just wasn't as big a deal for me then so I didn't complain about it.
) has a similar function, and the tree is lightning fast.