05-04-2025, 03:35 AM
Many little things can improve speed and performance. It all depends on what you're doing, when, where, and how complicated you want things to become.
Some general rules of thumb:
DO...LOOPS are faster than FOR...NEXT loops.
Working with ASCII values are faster than working with STRINGS. (IF ASC(text$,1) = 65 is faster than IF MID$(text$,1,1) = "A", for example.)
String addition is slooow. If you know you're going to add a bunch of strings together, add up the length, create one string that size, and then use MID$ on that string rather than adding them over and over repeatedly.
If writing to network files, write all your data to a local drive first and copy if over whole, instead of passing it one line at a time and waiting for it to pass network security and protocols.
If you need to read a file and can read it with LINE INPUT, open that file FOR BINARY instead of FOR INPUT. Even better, _READFILE$ and parse it yourself.
Skip use of POINT and PSET commands, using _MEM instead.
Use a default variable type that matches your system. INTEGER64 variables are faster to process on 64-bit machines than LONG, INTEGER, OR BYTE variables.
Never use _BIT. Forget it exists unless you're using it for a large bit array. Even then, consider it twice. Then consider it again. And then use _BYTE instead.
Set the flags in the compiler options to optimize your EXE. They make a huge difference in many cases.
Simplify your math and loops as much as possible, moving as much outside the loop as possible. This includes logic decisions such as IF or SELECT CASE. Sometimes you'll write more code, but the difference in performance can be truly worth it.
Never add a progress bar to a display. If you do, don't update it every 0.00001 percent. It takes time to print or draw to the screen and sometimes you'll spend more time on using making and using a progress bar in a loop than you'd use with the loop itself. Only update that bar as infrequently as possible to reduce any hit to performance.
Don't REDIM arrays by a count of 1. REDIM them much larger than you expect them to be, and then REDIM _PRESERVE them back down to the proper size afterwards. Each REDIM is a hit to performance. OVERDO it once, be done with it, and then resize it down. Don't grow it by one element over and over and over and over and over and over and over and over....
If you're using input for movement (such as in a game and such), you may want to use _KEYDOWN instead of _KEYHIT or INKEY$. Keydown is limited to the repeat speed of your machine. _KEYDOWN can generate a result with each pass of the loop. This can truly affect performance and responsiveness.
Umm.... Lots of other things I'm sure, but that's what I can pop off, off the top of my head.
Some general rules of thumb:
DO...LOOPS are faster than FOR...NEXT loops.
Working with ASCII values are faster than working with STRINGS. (IF ASC(text$,1) = 65 is faster than IF MID$(text$,1,1) = "A", for example.)
String addition is slooow. If you know you're going to add a bunch of strings together, add up the length, create one string that size, and then use MID$ on that string rather than adding them over and over repeatedly.
If writing to network files, write all your data to a local drive first and copy if over whole, instead of passing it one line at a time and waiting for it to pass network security and protocols.
If you need to read a file and can read it with LINE INPUT, open that file FOR BINARY instead of FOR INPUT. Even better, _READFILE$ and parse it yourself.
Skip use of POINT and PSET commands, using _MEM instead.
Use a default variable type that matches your system. INTEGER64 variables are faster to process on 64-bit machines than LONG, INTEGER, OR BYTE variables.
Never use _BIT. Forget it exists unless you're using it for a large bit array. Even then, consider it twice. Then consider it again. And then use _BYTE instead.
Set the flags in the compiler options to optimize your EXE. They make a huge difference in many cases.
Simplify your math and loops as much as possible, moving as much outside the loop as possible. This includes logic decisions such as IF or SELECT CASE. Sometimes you'll write more code, but the difference in performance can be truly worth it.
Never add a progress bar to a display. If you do, don't update it every 0.00001 percent. It takes time to print or draw to the screen and sometimes you'll spend more time on using making and using a progress bar in a loop than you'd use with the loop itself. Only update that bar as infrequently as possible to reduce any hit to performance.
Don't REDIM arrays by a count of 1. REDIM them much larger than you expect them to be, and then REDIM _PRESERVE them back down to the proper size afterwards. Each REDIM is a hit to performance. OVERDO it once, be done with it, and then resize it down. Don't grow it by one element over and over and over and over and over and over and over and over....
If you're using input for movement (such as in a game and such), you may want to use _KEYDOWN instead of _KEYHIT or INKEY$. Keydown is limited to the repeat speed of your machine. _KEYDOWN can generate a result with each pass of the loop. This can truly affect performance and responsiveness.
Umm.... Lots of other things I'm sure, but that's what I can pop off, off the top of my head.