06-23-2023, 01:15 AM
(06-22-2023, 11:50 PM)James D Jarvis Wrote:It's not for small programs. It's when your code starts becoming large with many different things going on where this kind of optimization matters. This is especially true in games where many different operations are going on at once. String manipulation is very CPU intensive and the cumulative effect of optimizations, such as keeping concatenation to a minimum, using integers where ever possible, avoiding square root and refactoring your algorithms to use only multiplication removing division, and using DO LOOPs instead of using FOR NEXT loops can really add up.(06-22-2023, 11:45 PM)TerryRitchie Wrote:(06-22-2023, 01:44 PM)a740g Wrote: VARPTR$ can come in handy when using DRAW or PLAY inside tight loops where you want to avoid the overhead and speed penalty of say string concatenation or other string ops.That's a valid point I should have addressed. When using STR$() more concatenation then comes into play slowing things down considerably.
Like in the example below, we avoid a string concatenation inside the FOR loop by using VARPTR$ for DRAW. This still works in QB64, thanks to the length Galleon went to emulate such things.
This is probably the only reason I'd use VARPTR$. Else, it is better to avoid such legacy commands.
So how's using STR$ inside draw routines bad and when does it come into play slowing things down? The speed of today's hardware really masks some of these things for me. I used to avoid DRAW because it was so darn slow but these days I've been having fun with it.