Messages

1

Find And Run Robot / Re: Slow performance on network shortcuts

« on: April 08, 2008, 09:19 AM »

Will do!

2

Screenshot Captor / Re: Multimonitor issue

« on: April 08, 2008, 09:12 AM »

Thanks! I don't understand why I didn't notice that  . I could swear it didn't work like that 2 hours ago... must be a glitch in the time/space continuum 

It's a little confusing that the (non-Red Box) selection box doesn't span multiple displays while the actually stored selection spans correctly, but I can definitely live with that.

Thanks for the quick reply! Case closed for me.

3

Screenshot Captor / Multimonitor issue

« on: April 08, 2008, 07:51 AM »

I use 2 monitors, with the primary monitor on the right. If I launch ScreenShotCapture (Grab Selected Region), it works great as long as the mouse remains on the primary display. The second I move the mouse to the secondary display however, the mouse cursor changes back to the default cursor and I can't capture anything. The same behaviour occurs if I launched a SSC shortcut while the mouse was on the secondary display. When I move back to the primary display, the cursor goes back to the selection cross, and I can use SSC the way it's supposed to work.

This means that I first have to move any window I want to capture to the primary display... 

4

Find And Run Robot / Slow performance on network shortcuts

« on: April 08, 2008, 07:41 AM »

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:

• 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!