Max CPU Usage

pgriffin · Post by **pgriffin** » Fri Mar 10, 2006 5:36 pm

I have a customer with critical apps running which I have created with MacroScheduler 7.4.

One program runs for 1st thru the 59th minute of each hour, this program calls 3 or 4 other programs based on what it finds in an Access database. We are having to stop/restart several times each day.

The PC has a gig of memory, plenty of processor.

Any ideas? they are close to pulling MacroScheduler from their system.

JRL · Post by **JRL** » Fri Mar 10, 2006 6:53 pm

Is CPU usage the problem?

If yes then look for a loop running wild. A small wait... something like Wait>0.01 in an otherwise untethered loop can cut CPU usage from 90% down to 2%

See:
http://www.mjtnet.com/forum/viewtopic.p ... t=cpu+loop

Or.. Is it the database that's causing the problem. Access queries will usually prevent me from doing anything else on my computer while they're running. I have 2 gig of RAM.

Later,
Dick

pgriffin · Post by **pgriffin** » Sat Mar 11, 2006 2:48 pm

I'm certain I do not have a tight loop running. Could it be that I am not correctly closing an ODBC connection to Access? The program also does a RetrievePOP3 every few seconds. Is that a potential problem? I have found that one of my programs requires that I break it up into 2 programs so it doesn't lock up during the day.

Post by **Marcus Tettmar** » Mon Mar 13, 2006 10:28 pm

Not closing an ODBC connection, or freeing activex objects may cause memory leaks, but are unlikely to result in increased CPU utilisation. Are you sure the problem is CPU utilisation, not memory usage?`

pgriffin · Post by **pgriffin** » Mon Mar 13, 2006 11:23 pm

I would not venture to say I am "sure" of much in this case. I can monitor the CPU usage in TaskMgr and see that it hits 100% from time to time. Each time I open an ODBC to Access I run a sub called DBclose....I never call an activex component....

I have a recurring clue. Everytime the I.S. mgr is out, the programs run perfectly. My question now is "what could she possibly be doing to cause the system to stop 'many times' each day?"

paul

pgriffin · Post by **pgriffin** » Tue Mar 28, 2006 3:21 pm

I may have solved this one, can't be sure. What I may have found is that my "greed for speed" is very expensive in terms of CPU cycles! Once I recorded the CPU Usage, (thank you Marcus) I noticed there were times in the script (not only the GUI intensive times) which I never pause the script. I added a one second WAIT> in a few places, slowed my scritpt to use wait>.25 instead of wait>.1 in a few places where CPU usage seemed higher, and VOILA!

My customer hasn't called in several days! The real rub is that I was the only one concerned with speed. My customer could not care less if the entry takes 11 seconds per transaction or 20 seconds per....as long as it goes in without issues....

How successful could I be if I could get out of my own way?

Post by **Marcus Tettmar** » Tue Mar 28, 2006 4:11 pm

Glad you sussed it. Yeh, tight waits will max out the CPU. I suppose we could modify the code to force a small delay internally after each step, or whenever the code branches. But I'd prefer to leave it to the user to decide when to force Waits and for how long. Hmmm. Food for thought.

JRL · Post by **JRL** » Tue Mar 28, 2006 9:23 pm

If there's a vote on that, I'd vote to keep the functions working as they are but to add examples of well placed wait>s in the help files.

For example, plagiarized from help:

Non-Modal Dialog Example

Dialog>Dialog1
Caption=Non-Modal Dialog
Top=113
Width=264
Left=16
Height=113
Button=Update,16,8,75,25,5
Button=Exit,16,48,75,25,6
Edit=msEdit1,104,8,121,Fred
ComboBox=msComboBox1,104,32,121,1%CRLF%2
Edit=msEdit2,104,56,121,
EndDialog>Dialog1

Show>Dialog1

Label>ActionLoop
GetDialogAction>Dialog1,r
if>r=5,Update
if>r=6,Close
if>r=2,exit

Wait>0.01

Goto>ActionLoop
Label>exit

SRT>Update
Let>Dialog1.msEdit2=%Dialog1.msEdit1% %Dialog1.msComboBox1%
ResetDialogAction>Dialog1
END>Update

SRT>Close
CloseDialog>Dialog1
Let>r=2
END>Close

Later,
Dick

pgriffin · Post by **pgriffin** » Tue Mar 28, 2006 9:35 pm

Because some scripts are SO time sensitive, I do not believe there should be a built-in Wait>, but should probably be in a "Best Practices" document in the help and/or somewhere in the Forum....

so, in short, looks like I agree with Dick.