How to get the most speed out your program?

[justsomeguy]

For those that are intimately familiar with the QB64 and its underlying code. What are some of the best ways to get more speed out of a program?

This is a short list of things that I have heard, but have not seen proven.

• Using '$CHECKING:OFF' in areas that need the most speed.
  
• 'DO ... LOOP' is faster than 'FOR ... NEXT'
  
• 'MEMPUT' in a loop is faster than 'MEMFILL'
  

Are there any other tricks or thing to avoid?

[Gets]

Memfill should be faster when using _BYTE. Years ago someone pointed out the difference in how QB64 handles that versus other variable types years ago and suggested that performance could be improved overall.

Variable type matters. When possible, INTEGER and LONG should be faster than SINGLE, for example. 

Time can also be saved by not putting code in a SUB or FUNCTION.  This is a hassle when it's time to make changes, so in the future I'll probably use precompiler commands to switch between methods.

[bplus]

I remember some speed was added to code by breaking an very large UDT array into multiple separate arrays.

[TerryRitchie]

When I write large libraries I create a copy of the library with all error checks removed.

I'm not talking about $CHECKING: but actual lines of code that checks for errors:

IF InputValue% > MaxAllowedValue% THEN Report_Error "blah blah blah"

Stuff like that. Once I have a piece of code working 100% that uses a library I then compile with a version of the library with all checks removed for speed. For instance, my sprite library consists of:

Sprite.BI
Sprite.BM
Sprite_Noerror.BM

Sprite_NoError.BM has no checks for valid syntax or values. That kind of stuff adds up and slows things down.

In fact, I'm just about finished with a complete rewrite of that old sprite library with an eye toward speed, efficiency, and easier to use. All those removed checks make a difference.

[SMcNeill]

Folks ask this type of question all the time, and it's always hard to give them a solution without seeing their existing code.

Are you wanting to improve file access time in your program?   Are you using OPEN file$ FOR INPUT, with LINE INPUT?   A simple change to OPEN file$ FOR BINARY would probably be 100 times faster.   Reading the whole file at once and just parsing it would be even faster.

Is the issue with the graphics being too slow?   Try to convert to Hardware images.   Still got issues?  Convert the code so the screen only updates the portions that change and leave the rest alone.

Are you having issues with strings?   Be certain to add the small strings before worrying over adding large strings.

x$ = large_string + small_string + small_string + small_string + small_string   <-- like here.   

As written, the above goes left to right, with large + small = large.   + small = large.  + small = large...   It's allocating large amounts of memory, adding/moving the contents of those other two strings into that new block of memory, and then freeing that large/small block of memory.

x$ = large_string + (small_string + small_string + small_string + small_string)   <-- this simple change is going to be faster as it's creating, moving, and freeing smaller blocks of memory, before finally merging with that large block.

x$ = large_string + ((small_string + small_string) + (small_string + small_string))  <-- and this will probably be even more efficient for the same reason.

---

Biggest factor for speed??

REMOVE AS MUCH AS POSSBLE FROM LOOPS!!

for y = 1 to 10000
For x = 1 to 10000
   _memput m, m.offset + (y * 1000 + x) * 4, kolor as unsigned long
Next x, y

^That's going to be quite inefficient.   How about this?

for y = 1 to 10000000 STEP 1000
For x = 1 to 10000
   _memput m, m.offset + (y + x) * 4, kolor as unsigned long
Next x, y

See that's one less math calculation inside the loop?   Let's keep going...

for y = 4 to 40000000 STEP 4000
For x = 4 to 40000   STEP 4
   _memput m, m.offset + y + x, kolor as unsigned long
Next x, y

Less math to do inside the loop there!  Can we keep going??

for y = 4 to 40000000 STEP 4000
For x = m.offset + 4 to m.offset + 40000 STEP 4
   _memput m, y + x, kolor as unsigned long
Next x, y

Well my goodness!!  Those FOR statements are certainly a little more complex than before, but the math we're actually doing inside that loop now is simple as heck!  This loop is going to be a TON faster than the previous one!

---

---

Mt personal advice?  Write the code to start with.  Get things working -- even if they work slow.   Only worry about optomizing for speed once you determine where the bottlenecks might be.

[bplus]

oh replace For loops with any other loop structure.

[Pete]

In QuickBASIC, using integers speed things up. DEFINT A-Z, etc. (I used DEFINT I-Z to free up A-H for other types.)

Anyway, I've never speed tested this in QB64 to see if it still makes any difference. Why? Because I have a computer that's too slow and the background processes interfere too much in the results. Damn Windows F'Updates! Oh well, it's good for writing jokes, as by comparison, it makes my wit seem a lot quicker than it really is. One day I hope to obtain a super computer that's faster than a jokamotive and can survive me throwing it off tall buildings in a single melt down. Trust, me, that sounds relatively funnier on my current system.

Pete

- If I had an apple for every great joke I told, I'd still be living in the Garden of Eden.

[a740g]

Compile the final executable with optimizations enabled. That alone should give a 2x - 4x (probably more) performance uplift.

[Pete]

Compile the final executable with optimizations enabled. That alone should give a 2x - 4x (probably more) performance uplift.

Custom compilation was a method in QuickBASIC, too. For instance if you didn't send anything to the printer, omit the printer subroutine. I still remember the most common optimization switches I used: OSEX. Gee, I wonder how that one got committed to memory? 

Anyway, could you share an example or Wiki link as to how to accomplish this in QB64?

Pete

[bplus]

Compile the final executable with optimizations enabled. That alone should give a 2x - 4x (probably more) performance uplift.

Custom compilation was a method in QuickBASIC, too. For instance if you didn't send anything to the printer, omit the printer subroutine. I still remember the most common optimization switches I used: OSEX. Gee, I wonder how that one got committed to memory? 

Anyway, could you share an example or Wiki link as to how to accomplish this in QB64?

Pete

IDE Menu Options > Compiler Settings
   

Looks like you need to know some C++


brought to you by know-tube