BlitzMax Preformance Howto

Hi,

I have a few questions concerning preformance.

1) Is it faster to use INT or BYTE for values <255 (e.g. boolean or small values)?
2) Is it faster to use local variables -or- references to variables inside its class (using Self.)?
3) Is it faster to use local variables then global variables
4) Is it best to wrap sections of code in classes, or functions, or just plain. (e.g. for localisation / garbage collecting?)
5) Is it faster to define Local outside, or inside a loop? (i think the awnser is obvious)
5) How do i free pictures, objects, sounds, values, etc... form memory?
6) Do i need to know anything concerning unloading?
7) Anything else i should know concerning preformance?

-edit-
8) Is it faster to use FLOAT or INT?

p.s. it seems that INT is faster than Byte?!?!

No, I think that has been stated before.. somewhere..

Considering the rounding and whatnot that has to happen with floats, I would assume not.

32bit processors operate on 32bit numbers faster than operating on 8 or 16 bit numbers.

1) Int is faster than byte so sayeth the sibly
2) Not sure what you mean.
3) Locals can be faster, but only if they are primitive types, otherwise they are effectively stored like globals.
4) it's a matter of preference, personally I find OO a much easier to use method.
5) It depends on what you are doing I guess.
6) null all references to them and allow the GC to collect, or null all references and call GCCollect()
7) probably
8) Int

ok, thansk for the replies!

I figured:

1) INT is faster then BYTE.
2) not sure yet.
3) Is it faster to use local variables.
4) doesnt really matter.
5) Not sure, but it seems it is faster to define Local outside a loop, otherwise it has to remake it everytime it loops, instead of write into the already made available space of the variable?
5) try using unload commands, afther that just NULL them out for GC.
6) Probably :-P
7) -
8) It is faster to INT then FLOAT.

Thanks to all! ( i did some testing too )

None of this will really make much impact on speed. Your biggest bottleneck is likely to be graphics drawing (and sometimes intense math, eg. physics). You should really concentrate on readability (and reusability and functionality) rather that concerning your self with tiny speed increases. If you really want to make a difference follow these rules:

1) Use SuperStrict
2) Always use Locals where possible.
3) Use OO principles. Preferably consistantly.
4) Use Ints and Floats as needed. Avoid Bytes etc.
5) Optimise at the last possible moment and only when really necessary.

Also check out my thread here http://www.blitzbasic.com/Community/posts.php?topic=82204 about slow drawing routines.

Depending on the data your sending/receiving, bytes might be better to use over the network, for size purposes.

Avoid dynamically allocating objects and memory whenever possible.

Thanks for the input guys! Greatly appreciated.

Bytes take less room for storage too (in RAM and on disk) but that's probably not much of an issue now unless you have HUGE arrays.

Yeah like using particle pooling. However, I don't use that and my games are still fast enough.

I second what Beaker wrote. Other than that...

Any of the things you mentioned won't have very much effect. If you find you *need* to optimize, the best bet is to choose a faster algorithm. Only once you have the best possible algorithm for what you are doing and *still* need speed should you optimize the implementation.

If it comes to that, which I doubt, avoid creating objects and calling functions inside loops that run through many times every cycle. If you know C, implementing critical parts in C may help because GCC inlines quite a lot.

Edit: For example, all the BRL.Math functions actually result in a function call, whereas in C most of them would get compiled to a single assembly instruction.



Local variables of primitive types are usually not really "created". They are just symbols for referring to a register, so that shouldn't make any difference. Reducing the number of locals probably won't make any difference at all.