Maybe it Is only my imagination but reading big directory in Opus 10 is noticeable slower than in Opus 9. Can anyone confirm that?
No, on my machines it´s as fast as always. Do you maybe use some sophisticated column settings since the new version?
The calculation of certain columns can take up quite some time, like file or subfolder counts.
for me the find command with using a filter is noticeable slower.
in version 9 when i used FIND to search on couple locations for folders with modified date which matches my filter to put the result in a filecollection and when i finaly found all relevant folders i copied the content of the collection to a specific folder.
in version 10 opus starts to copy but is still looking for modified folders.
and of course I use the @async dopusrt /CMD FIND FILTER=...
my actual workarround for this is to place a @confirm before the copy thing starts. i'm not sure if this problem may depends on somethng other. directory reading is for me as fast as before...no problems threre...
Yes. I find it to be significantly slower.
Hi leo.
What does that above setting do?
It makes Opus show the names of certain folders using your language rather than the real names.
e.g. On disk, Program Files is always called Program Files on Windows 7, no matter which language you use, but Explorer (and Opus if that option is on) will show a different name for it if you're not using English. Looking up the names can add some delay.
(As usual, Microsoft designed the API so it worked great as a wrapper around exactly what Explorer needs but was a pain for anything else to use.)
I just turned the above setting off.
Not sure if it is in my mind, but Directory Opus definitely seems snappier to me.
This option is ticked but ghosted for me. Not sure what that means.
You're using Windows XP?
Ah yes, that'll be it. I use a KVM to toggle between PC's so I never know if I'm arthur or martha
Cheers
Speeds things up quite a bit. Happy camper again now. Thanks
I was also getting pauses (delays) when opening some folders.
So far, so good, now.
Which columns do you use in those folders?
Which columns do you use in those folders?[/quote]
I mainly use "Details View".
Name
Size
Type
Modified
Attr
I do NOT calculate folder sizes automatically, though.
There should be no problem using those columns. A few, like file counts are known to slow down the listing a bit, in some cases. Maybe some on-access firewall
or antivirus modules are responsible. If you use any, it´s worth checking. Ususally you can disable those modules in the firewall settings.
I don't use a third party firewall and use Microsoft Security Essentials for my antivirus.
Since protocol said "was" and "so far, so good, now", I'm assuming turning off localised names solved the problem and we don't need to dig into his columns.
I'm not sure that the folder-size and/or child-count columns would make much difference, either. Those get calculated in the background after the directory has been read, so they wouldn't slow down directory reads. (Well, not in the current window. If the calculations are being done and keeping the disk busy reading sub-directories then that might slightly slow-down reading directories in another window or a dual display.)
Problem seems to have returned despite adopting Leo's solution above. If I open three tabs (each to a folder on a separate physical drive) it takes about 10 secs before the display updates when moving between drives. The funny thing is this time seems to be roughly constant irrespective of the size of the folder being accessed. It's getting to the point where this is becoming unworkable. Any ideas?
Changing from one open tab to another doesn't involve reading directories -- the dirs are read in the background as soon as the tab is created -- so I'm not sure whatever your seeing is related. Not sure if I've interpreted what you said correctly, though?
(Exception: Clicking on a "locked (allow change)" tab that had had its folder changed will cause it to re-read its original folder, of course.)