CPU-Usage

Technical support and scripting issues

Moderators: Dorian (MJT support), JRL

Post Reply
Hardware_Tester
Pro Scripter
Posts: 58
Joined: Mon Jun 27, 2005 7:03 am
Location: Switzerland

CPU-Usage

Post by Hardware_Tester » Fri Jan 06, 2006 3:07 pm

I have problems with an old machine polling the menue. It is a P2 with 233MHz.


Label>GUI
wait>0.3
GetDialogAction>panel,result
If>result>25,runTool
If>result=2,OUT
goto>GUI


The menue is quite huge with 10Checkboxes, 10Comboboxes, 2Filebrowse and 4 additional Buttons.

When the wait is 0.05 the load is 41%, with 0.1 it's 25%, with 0.3 it's 15%. This is quite much, compared with other applications which have =0% usage when a dialog is open.

The Operating System is a Win2k with SP4. I checked the task manager, Ram was not the problem (128M)

User avatar
Captive
Macro Veteran
Posts: 213
Joined: Sun Oct 20, 2002 8:37 pm
Location: Colorado, USA

Post by Captive » Sat Jan 07, 2006 12:13 am

If you have a script infinately loop and do something, then it'll share 100% cpu time with other active applications.

If you have the script wait a fraction of a second, the other applications (or the system idle time) will take those CPU clocks instead.

There's nothing wrong with the numbers you quote. That's the nature of math and CPU clock cycles.

User avatar
support
Automation Wizard
Posts: 1450
Joined: Sat Oct 19, 2002 4:38 pm
Location: London
Contact:

Re: CPU-Usage

Post by support » Sat Jan 07, 2006 9:08 am

Hardware_Tester wrote:IWhen the wait is 0.05 the load is 41%, with 0.1 it's 25%, with 0.3 it's 15%. This is quite much, compared with other applications which have =0% usage when a dialog is open.
Yes but those applications are not written with a scripting language like Macro Scheduler which is very high level - they are compiled. You have a loop so each iteration consumes cycles. But don't worry, Macro Scheduler will not take resources away from other processes. It will only take what is available.
MJT Net Support
[email protected]

Hardware_Tester
Pro Scripter
Posts: 58
Joined: Mon Jun 27, 2005 7:03 am
Location: Switzerland

Post by Hardware_Tester » Sat Jan 07, 2006 12:21 pm

I know this, but has it to be so much??

Compared with java, which is also a high level language and runs on a runtime. I think there is much space for optimizing it. Also the saveplace of the exe - much functions like the mail and ftp engine could be optimized away when they are not used.

I tryed it on the other PC, a P4 with 2.26 GHz and also Win2k SP4. There were only 17 copyed necessary to slow down the system. Only for 6 lines of code with one complex call, the others are low level commands which you can find in assembler languages.

User avatar
Marcus Tettmar
Site Admin
Posts: 7380
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Sun Jan 08, 2006 9:05 pm

You cannot compare Macro Scheduler to an object oriented language with support for threads and a full featured visual object library. Macro Scheduler is an automation tool. Java is a programming language with a JIT compiler and selective run time environment. Both are designed for doing different things. If you want to make full featured GUIs and slick Windows interfaces don't use Macro Scheduler. If you want to automate Windows applications you'll find it quicker and easier with Macro Scheduler than building it all yourself in Java. There are of course overlaps and you can also combine the two, but they cannot be compared like for like.

To handle a non-modal dialog in Macro Scheduler you create a high level loop. In contrast Java will use a thread containing a very low level message loop and event procedures in a separate thread for each Window. Macro Scheduler does not provide such things - and I'm not convinced it should - our aim is not to create a programming language for designing Windows applications - it is meant to be a scripting language for *automating* Windows applications. Custom dialogs are useful for creating basic dialogs for getting info from the user but are not intended to replace, or to be used for building, full on windows interfaces. For that use VB or C++ etc.

All that said we are always working on improvements and if we can make any improvements re the performance of non-modal dialogs and loops we will.
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

Hardware_Tester
Pro Scripter
Posts: 58
Joined: Mon Jun 27, 2005 7:03 am
Location: Switzerland

Post by Hardware_Tester » Sun Jan 08, 2006 10:00 pm

In my situation I had to use a dialog for letting the user make some settings like port-assignement and file locations. Are dialog windows with less objects better than some with more, in other words: Is it better to create an extra options-dialog and a small main dialog instead a one single dialog?

User avatar
Marcus Tettmar
Site Admin
Posts: 7380
Joined: Thu Sep 19, 2002 3:00 pm
Location: Dorset, UK
Contact:

Post by Marcus Tettmar » Sun Jan 08, 2006 10:11 pm

Hi,

The dialog makes no difference. It is the looping that consumes cycles. Even this code will use a lot of CPU time:

Let>x=0
Label>start
Let>x=x+1
Goto>start

It really has nothing to do with the dialog. It is the looping. You can make things better by making each loop iteration wait and therefore yield to the processor:

Let>x=0
Label>start
Let>x=x+1
Wait>0.5
Goto>start
Marcus Tettmar
http://mjtnet.com/blog/ | http://twitter.com/marcustettmar

Did you know we are now offering affordable monthly subscriptions for Macro Scheduler Standard?

Post Reply
Sign up to our newsletter for free automation tips, tricks & discounts