Minimize impact of QB64 programs in background

[Richard]

So I have been getting practice with running QB64 programs in the background (both via Task Scheduler and Start Up).

I wish to arrange it that the programs have MINIMUM impact on my computer as they do not actually do much but are timetabled every 10 minutes to do a short task (1 millisecond) and then nothing but wait till another 10 minutes for the whole cycle to be repeated.  Essentially the code goes like this...

Check if current time is on the 10-minute mark    (right$(time$,4)="0:00")
If so do SOMETHING (1 millisecond), delay 2 seconds (be sure NOT on the 10-minute mark)
GOTO Check line above.

What is the best way to cut down on system resources for these BACKGROUND Tasks?

[TempodiBasic]

What about _LIMIT  in the main loop?

[SpriggsySpriggs]

Try making them $CONSOLE:ONLY as well.

[Richard]

@SpriggsySpriggs

In my background programs - after the initial minute during which I get confirmation that the background program is ACTUALLY running - _SCREENHIDE is used so that for the next 48 hours or more NO BACKGROUND PROGRAM DISPLAY is visible anywhere.

Would, in this case, $CONSOLE:ONLY, make any difference (after the first minute)?

[Pete]

While running in the background, _SCREENHIDE, just include and set, as Tempo indicated, the _LIMIT to a very small value, possibly 1. Additionally, SLEEP with a value could be used like SLEEP 10. So now the program rests for 10 seconds before performing th next background cycle.

Pete

[SMcNeill]

DO
    ‘do whatever
    _DELAY 600 ‘idle for 10 minutes
LOOP


I can’t imagine it getting much simpler than that, and you’re not going to have lower resource consumption than that.

[Pete]

LOL Steve just cat-proofed it! That's the benefit of the _DELAY QB64 keyword over the traditional SLEEP statement. The downside is you'll have to make a way out, if you want your program to come back on screen before the timer is set to bring it back to the screen. The easiest way to do that is to trade out the _SCREENHIDE for a minimize routine like _ICON or using a Windows API call. Of course if you don't own a cat, especially my cat, just use SLEEP 600. When you press a key, the SLEEP cycle breaks.

Pete

[Richard]

@SMcNeill
@Pete
@TempodiBasic

Thanks above.

I have just restarted a TaskScheduler BackGround QB64 program with the following modifications (with _SCREENHIDE)

SLEEP 599
_LIMIT 2   ' 2 loops per second

and see if I miss out on any "10 minute heart-beats"

I will also try
_DELAY 599
_LIMIT 2

What is the difference, if any, between resource consumption DELAY versus SLEEP?

I may need to run each of above trials for say at least 24 hours just to see how many, if any, misses occur.

[SMcNeill]

_LIMIT is the maximum number of times a loop repeats in a second, _DELAY is a pause for a number of seconds.

http://www.qb64.org/wiki/LIMIT
http://www.qb64.org/wiki/DELAY

You can’t have a limit of less than 0.127 (one loop per minute), so in this case, it just makes more sense to use a singular _DELAY to keep the loop from repeating for a 10 minute interval.  (Unless, as Pete suggests, you might need to interact with the program to unhide or chose it in that time.)

[Pete]

I can't say there is a difference in resource usage between SLEEP and _DEALY. I would think, by the similar way they function, they would use close to the same; but the SLEEP function does have to extend some resources for a key press. By that logic, one would think _DELAY would be the lesser of the two resource hoglets. I'm not all that interested in resource testing out that hypothesis, so maybe someone else has a more definitive answer.

Pete

[Richard]

@Pete
@SMcNeill

Thanks for replies

Just restarted my system with

1x TaskScheduled Background QB64 Program   (SLEEP 599  LIMIT 2)   running at about 2% CPU (according to Windows 10 Task Manager)
5x StartMenu Background QB64 Program   (no sleep  DOING NOTHING except reading keyboard infinite loop) each running at about 14% CPU (...)

I hope that using DELAY 599 instead of SLEEP 599 gives improvement. Will try after present run for many hours.

Am a bit concerned that IF I use 600 instead of 599, that over a long period of time (say 1 day) - that timing round-off errors may cumulate to result in missing "beats" - suppose I should also do 600 trials (3 days +) to see.

Actually - in my intended use - there will be no need for keyboard, display - (I save a tiny bit of data to disk). Because I plan to run Background programs up to 3 or more days at a time - my solution to stopping is Task Manager End Task or "red X" it to stop. Generally speaking, Windows 10 for me becomes UNSTABLE or VERY SLUGGISH after a few days CONTINUOUS USE - so often I have to use "brute force" by shutting the whole system down.

[Pete]

Or you could make a program to TASKKILL your QB64 program, make a desktop shortcut to it, and click it to end your program. Something like...

Code: QB64: [Select]

1. SHELL _HIDE "TASKKILL /F /IM myqb64prog.exe"
2. SYSTEM

Pete

[Richard]

Just started my TaskScheduled Background QB64 program but with _DELAY 599 instead of SLEEP 599

There is only a marginal improvement in CPU resource usage  - about 1.8% (with DELAY) compared to about 2% (with SLEEP). The running programs with an inkey$ loop are at about 13%.

Yes there is a noticeable reduction in CPU usage (using SLEEP or DELAY) - so it seems quite a bit is going on still in behind the scenes with QB64 programs. I used Windows 10 Task Manager as my CPU% monitor.

Maybe some others may be interested in trying this LONG program

Code: QB64: [Select]

1. _SCREENHIDE
2. _DELAY 10000
3. END
4.  

it is running at present at about 1.2% CPU on my laptop

EDIT  added an extra line to program - after say 1 minute TaskManager reports 0% CPU usage. My TaskScheduled Background QB64 program is running at about  1.3% CPU

[SpriggsySpriggs]

$CONSOLE:ONLY
_CONSOLE OFF

[Pete]

As long as you have an error free version up and running, try adding...

$CHECKING:OFF

.. at the top of your code.

https://www.qb64.org/wiki/$CHECKING

Pete