Virtuous programming techniques...

[krovit]

Hello everyone, wherever you are!

A general question:

How much does the use of CALL affect the use of resources (CPU, memory and more) in terms of resource exploitation?
For example, does the massive use of '$ INCLUDE instead of CALL damage system and program performance?
And the use of COMMON SHARED or DIM SHARED, in the same way, damages them?

Thank you!

[_vince]

A literal include will take up more RAM as a CALL allows you to reuse the same code by jumping to it and returning to where you were.  Since it takes some time to jump to it, it will run a bit slower.  The same goes for LOOPs, literally typing out the 'unrolled' loop will run faster. Similar goes for SHARED vs. parameter passing, memory used up by parameters is freed to be reused after the CALL but SHARED will keep it occupied the entire program run time but might make your sub run faster.

It's up to the programmer to cleverly decide when he should save memory at the expense of speed or vice versa. I would say that in general, unrolling CALLs and LOOPs should be avoided unless you are really sure that the performance gain isn't trivial

[Richard Frost]

Minimizing memory usage seems rather pointless, most of the time.  It was an
issue with QB4.5, where one could run out of it a lot easier. 

Some tricks for improving speed are:

1) Use LONG variables.  They're the fastest.  DEFLNG A-Z at the start of the code defaults
   all vars LONG unless specifically typed otherwise.  Why LONG is faster than INTEGER I
   don't understand.
2) DO and WHILE loops are faster than FOR:NEXT
3) branchless programming:
   IF var1 > 5 THEN var2 = 77 ELSE var2 = 0
     can be replaced with
   var2 = (var1 > 5) * -77
4) Avoid strings in loops that are critical to program performance.  String processing
   is hellishly slow.

I don't know if old tricks like using lookup tables for trigonometric functions matter
with QB64 and modern computers.  But it's easy enough to test. 

For most programs, QB64 is so fast that the issue is to SLOW IT DOWN, not speed it up.
Sprinkling in a few _LIMITs and/or _DELAYs prevents old QB4.5 code from transforming the
CPU into a toaster oven.

[krovit]

Thank you... in general I imagined something like that but you have given me precise and tranquilizers indications.

3) branchless programming:
   IF var1 > 5 THEN var2 = 77 ELSE var2 = 0
     can be replaced with
   var2 = (var1 > 5) * -77

I didn't know the ability to compose code that way !!

Strange this thing about the LONG variables... I, by default, always defined them all INTEGER thinking it was the best thing.

I would say that in general, unrolling CALLs and LOOPs should be avoided unless you are really sure that the performance gain isn't trivial

Too many CALLS could be a problem? Damn it! Certain programs live from calls to CALL routines.

[_vince]

Too many CALLS could be a problem? Damn it! Certain programs live from calls to CALL routines.

I meant the opposite

[krovit]

__vince, thank you!

the world had collapsed on me!

you do it to say... but when certainties falter (like call is a blessing...) you get shaken...

Sorry... i'm bad in foreign languages