Using FARR at home, I can always count on its speed to give me what I want: it's a wonderfully reliable tool! At work however, it blocked sometimes for more than 20 seconds(!) while typing, making its use rather limited.
After an investigation with the unequalled Sysinternals Process Monitor, I could track the slow response to the following situations:
The delay with network shortcuts was already mentioned in older threads (e.g. "Stalls for 3-4 sec" dating december 2005), but doesn't appear to be fixed yet. I resolved the slow performance with the following techniques:
Now I'm finally back to responses under one second
, but this work took quite some time, and limited FARR's use. I'll probably need to redo the analysis within a couple of months if I create too much network shortcuts again.
Wouldn't it be possible to just investigate the shortcut file (*.lnk) in the search path, rather than the file and/or path it actually points to? That would really be a major performance boost in a networked environment!
After an investigation with the unequalled Sysinternals Process Monitor, I could track the slow response to the following situations:
- shortcuts to files/folders on mapped network drives, but where the server itself changed name. When you open up the shortcut's properties, you just see something like "S:\shared\...", but when you look at the shortcut file itself, it contains a reference to the actual server, e.g. "\\jupiter". If that machine doesn't exist anymore (or is renamed to "\\fileserver"), you can get a delay of 20 seconds, even if it's a local LAN shortcut
- every shortcut results in disk access not just to the shortcut itself, but also to the file or folder it points to (together with all intermediate paths to that file/folder). If your shortcut points to a LAN file, you might get a delay of 0.5 seconds for each of those shortcuts. If your shortcut points to a file on the WAN, e.g. to a shared folder in another continent,... your luck has ended (couple of seconds delay).
The delay with network shortcuts was already mentioned in older threads (e.g. "Stalls for 3-4 sec" dating december 2005), but doesn't appear to be fixed yet. I resolved the slow performance with the following techniques:
- updated all shortcuts containing old server references
- excluded as much network shortcuts from the FARR search folders as I could (excluded 300 network shortcuts to different machines/logfiles/...), limiting FARR's use however
- replaced any remaining shortcuts to network tools with "cmd /c ...", making it a local reference starting the actual application
Now I'm finally back to responses under one second
, but this work took quite some time, and limited FARR's use. I'll probably need to redo the analysis within a couple of months if I create too much network shortcuts again.Wouldn't it be possible to just investigate the shortcut file (*.lnk) in the search path, rather than the file and/or path it actually points to? That would really be a major performance boost in a networked environment!
