Simple speed test macro

[terrypin]

This is still about my mysterious slowing down issue. I've now written an ultra simple macro that suffers from exactly the same problem. I'd appreciate others trying it at regular intervals to see if they also ever get the problem please.

 

Repeat Start (Repeat 10 times)
 Mouse Move: 100, 100 Relative to Screen
 Repeat Start (Repeat 500 times) // Repeat indefinitely
   Mouse Move: 1, 0 Relative to Last Position // Move 1 pixel to the right
   Delay: 1 milliseconds, without ability to halt
 End Repeat
End Repeat

 

<REPEAT START Start="1" Step="1" Count="10" Save="FALSE"/>
<MOUSE MOVE Option="\x01" X="100" Y="100" _PROMPT="0x000A"/>
<REPEAT START Start="1" Step="1" Count="500" Save="FALSE" _COMMENT="Repeat indefinitely"/>
<MOUSE MOVE Option="\x03" X="1" Y="0" _PROMPT="0x000A" _COMMENT="Move 1 pixel to the right"/>
<DELAY Flags="\x03" Time="1"/>
<END REPEAT/>
<END REPEAT/>

 

All it does is move the mouse cursor across the screen 500 pixels, repeating that 10 times. When everything is OK (what I've called 'fast mode'), each move takes about 1 sec, so 10 seconds altogether. But in 'slow mode' it takes about 6 times longer.

 

After a week investigating this I still don't know if it's my PC setup or something to do with ME Pro. So feedback on this test would be much appreciated please.

 

--

Terry, East Grinstead, UK

[terrypin]

I'm delighted to report that at around midnight I finally stumbled across the cause! And to call it 'obscure' would be an understatement. In short it's a bizarre conflict with a great little free program called AWC I've been using for ages. Steve Murphy's Automatic Wallpaper Changer, Version 3.0.8.

http://awc.smurphy.co.uk/download.htm

 

It simply displays random images from any large folder onto the desktop at chosen intervals. But get this: it's not running the program that causes the slow mode - it's closing it!

 

During this whole saga I've typically closed as much stuff as possible after a fresh re-boot, to help isolate the problem. So amongst other things I would right-click the AWC tray icon and select Exit. The breakthrough last night came when I happened to try my test macro immediately after doing that - and found it slow. I re-loaded AWC: fast. Closed it: slow. Eureka!

 

I've no idea what the underlying cause is. I'm off to download the latest version. If that has the same issue I'll post on the AWC forum. Now maybe I can concentrate on some productive work!

 

--

Terry, East Grinstead, UK

[terrypin]

I've now installed the latest version of AWC, but am disappointed to find it still gives the same problem. Of course, I can now easily avoid it by not switching it off. But I'd like to get to bottom of it. so I've posted to the AWC forum.

 

If anyone cares to try this with my simple test macro, AWC is at http://awc.smurphy.co.uk/download.htm

 

BTW, can anyone think of a more easily accessible program (maybe built in to XP) that will move the mouse cursor around please? I'd like to use it when discussing this behaviour with those unfortunates who don't have Macro Express.

 

--

Terry, East Grinstead, UK

[terrypin]

I eventually thought of another more easily available application that can record mouse cursor movement and then play it back. The 17-year old Microsoft Recorder.exe does the job nicely. (Originally Windows 3.1 I think.) I've regularly transferred the 4 files

RECORDER.DLL

RECORDER.EXE

RECORDER.GID

RECORDER.HLP

over from successive PCs during that period, although at the last upgrade to this PC, 16 or so months ago, I didn't do so. But a quick visit to my shed with a memory stick sorted that and I now have Recorder running here. Still a great little tool BTW!

 

Also, while I was running the shed PC (a 6 or 7 years old Athlon) I loaded my test Macro Express macros and AWC and confirmed exactly the same slow-down problem. So that eliminates any residual worries that it might be hardware related as well as involving AWC.

 

Then back on this PC, for the first time I was able to try exiting AWC and see the effects on something other than my ME test macros. I recorded fairly fast mouse cursor movement with Recorder, and tried running it both with AWC running and after I closed AWC from the tray. They were identical, both fast.

 

So ... this appears to be an issue that affects Macro Express macros but not necessarily anything else. I can't really be sure of course, because all I've done is prove that it doesn't affect Recorder macros (a 16-bit application BTW, FWIW). But it does put focus back on ME Pro as well as AWC. And the worry remains that it may be some sort of generic issue, which can be triggered by other as yet unknown events, apart from the present bizarre but very real case of closing AWC!

 

One other thing I suppose I should try is to re-write the test macro for ME 3, and see whether that too switches into slow mode when AWC exits. I was rather hoping ISS might join in too!

 

It's very unclear to me what could cause this when AWC exits, as the process AWC.exe is no longer running. But presumably programs can terminate 'badly'? IOW, damage or corrupt something else, or leave fragments of their memory behind, whatever? Is that possible?

 

P.S: Paul, it's possible this sort of issue might be involved in your problem too.

 

Edit: Here's a short movie showing the effects of AWC closing

- on the ME Pro macro (slows it down)

- on the Recorder macro (doesn' t affect it)

 

http://s154.photobucket.com/albums/s247/te...CMEPProblem.flv

 

--

Terry, East Grinstead, UK

[terrypin]

Repeat Start (Repeat 10 times)
 Mouse Move: 100, 100 Relative to Screen
 Repeat Start (Repeat 500 times) // Repeat indefinitely
   Mouse Move: 1, 0 Relative to Last Position // Move 1 pixel to the right
   [b]Delay: 1 milliseconds, without ability to halt[/b]
 End Repeat
End Repeat

 

Continuing this solo discussion with myself ... I may be onto something. If I change that delay command to

Delay: 1 milliseconds

then the big speed drop doesn't happen.

Is that to be expected? I can't quite get my mind around it. In fact I think I'd have expected the reverse, because according to Help, "The Timed Delay in Seconds option puts Macro Express into a "wait state" where virtually no CPU cycles are used, thus allowing CPU intensive programs to continue uninhibited."

 

I've now formally raised this as a support issue with ISS, but I'll keep this thread going too until some sort of consensus or conclusion emerges.

 

--

Terry, East Grinstead, UK

[Cory]

Continuing this solo discussion with myself

I've been reading your posts and reckoned you would eventually do some more testing to try and narrow it down. Thru the beta days even there seems to be some strange overhead on some seemingly simple commands and you may have found another.

[terrypin]

Continuing this solo discussion with myself ... I may be onto something. If I change that delay command to

Delay: 1 milliseconds

then the big speed drop doesn't happen.

Is that to be expected? I can't quite get my mind around it. In fact I think I'd have expected the reverse, because according to Help, "The Timed Delay in Seconds option puts Macro Express into a "wait state" where virtually no CPU cycles are used, thus allowing CPU intensive programs to continue uninhibited."

 

I've now formally raised this as a support issue with ISS, but I'll keep this thread going too until some sort of consensus or conclusion emerges.

 

I know that, like me, Cory for one appreciates conclusions (no missing pages at the end of that paperback). So I'm closing off this thread and the one that preceded it with a summary of the outcome.

 

Jason got back to me today and confirmed that my practical experiment was correct:

"It appears that AWC is causing Macro Express to ignore the Delay commands within the loops. Specifically, it is a conflict in the Timed Delay command. If you switch the command to Delay in Milliseconds instead of Timed Delay in Milliseconds, you should no longer see the speed difference."

 

I had also established earlier that I'd been thinking about this wrongly. Instead of the issue being 'AWC is somehow causing this macro to slow down when AWC is closed', which is the way I'd been approaching it, I realised I should be wondering why 'AWC is somehow causing this macro to finish more quickly when AWC is running'?

 

I arrived at this because when I removed AWC from the Startup folder and rebooted, the macro still ran slow. I suppose there could be some other obscure cause, but the hypotheseis above seemed the most logical to me. And Jason's tests confirm it. In fact in hindsight it seems daft that I should have entertained the idea that stopping a process (AWC) was causing a performance drop in ME Pro!

 

It remains a puzzle just why AWC has that effect (I've informed the author). And indeed why ME Pro isn't sufficiently 'isolated' from external processes to allow such interference. And of course the question also remains as to whether any other programs affect ME Pro in this way. But happily, providing I avoid that particular flavour of delay command, I can now run ME Pro and AWC together with confidence!

 

--

Terry, East Grinstead, UK

[chris]

Fortunately, it's only isolated to the "Timed Delay with no ability to halt" option of the "Delay" command. In order to obtain that kind of a delay, we use a system object called a "Semaphore" (which is a system object used for timers). The reason behind that is simply for compatibility since I can't ask Mike (the author of Macro 2.x) why he used it.

 

Normally, this object is safe to use because most programs do not use it. But, in this case, AWC uses the exact same semaphore (specifically, the global, unnamed semaphore. I tried using named versions, but that actually caused some significant problems). But, what AWC is doing is they're not resetting its state, so when Macro Pro attempts to use the semaphore for the delay, the OS just blows MEPro's request off, thus causing the situation where there is no delay.

 

Since this is the only global, unnamed object in use by MEPro, it's the only command that can be affected by another program. All other global objects are named, so unless another program is intentionally malicious, they won't be affected.

 

This "effect" can be worked around by using any other delay option.

[terrypin]

Fortunately, it's only isolated to the "Timed Delay with no ability to halt" option of the "Delay" command. In order to obtain that kind of a delay, we use a system object called a "Semaphore" (which is a system object used for timers). The reason behind that is simply for compatibility since I can't ask Mike (the author of Macro 2.x) why he used it.

 

Normally, this object is safe to use because most programs do not use it. But, in this case, AWC uses the exact same semaphore (specifically, the global, unnamed semaphore. I tried using named versions, but that actually caused some significant problems). But, what AWC is doing is they're not resetting its state, so when Macro Pro attempts to use the semaphore for the delay, the OS just blows MEPro's request off, thus causing the situation where there is no delay.

 

Since this is the only global, unnamed object in use by MEPro, it's the only command that can be affected by another program. All other global objects are named, so unless another program is intentionally malicious, they won't be affected.

 

This "effect" can be worked around by using any other delay option.

 

Chris, That's a revelation - and great to find someone else who has encountered the issue! Do you mind if I forward a copy of your post to Steve Murphy, AWC's author?

 

--

Terry, East Grinstead, UK

[chris]

Sure thing.

[terrypin]

Received today from ISS Support:

"Issue [iSS6988] submitted by you has been resolved. The change will be available with the next release of Macro Express Pro."

 

--

Terry, East Grinstead, UK