you still have not indicated the "domain of the problem" in regard to
how critical the "size" and the "speed" are.

this leaves a lot of room for bad guesses and wasted time and resources.

for example:

is this embeded?

is it machine to machine level operations ?

is it machine to human ?

is it "Human life critical" as in a person could die if it fails ?

is it more size constrained than speed or the opposite?


generally in most code you trade one for the other.

like taking a loop and runrolling it you may make some code faster by making it larger.

so often the "Fast" code is large and the "Small" code is slower.

but how much that matters depends on the use of it.

so I'd look at how it's used and then see what the constraints are and then decide how to impliment the code.

that's if the need to lock down the size and speed are that great.

even in most games you spend the most work in things like painting the screen, user input is generally a factor of x10 or x100 or x1000 slower than the screen draw.

so you could write the userinput in script as long as the drawing system was fast.

just one extreem example of what I am trying to get at.