I am stating the following MOSTLY from experiences, rather than written facts.

I BELIEVE the embedded commands give a small improvement.
And some of them more than others. I do the embedding as a personal
preference towards compact code more than speed.

I'll use the example of 'vec_normalize' to SUGGEST there is some speed
improvements to be gained by embedding.
'vec_normalize' CAN be embeddind in other commands, but you will see that
I never do so. That is because OCCASIONAL compiles will generate a
'empty pointer' error at run-time at the 'output' time of the vec_normalize.
I suspect that the embedding is 'out running' the commands ability to update the data.
Whereas exactly the same code JUST with the 'vec_normalize' NON-embedded works fine.
This SUGGESTS that the embedded code is running faster.
I have never actually tried any time-elapsed tests...

But I know for a FACT that creating/destroying LOCAL vars does slow things down.
Thats why you will often examples of my code around that use STATIC local vars.
These only get created once, but CAN cause problems if more that one instance of
that function is running, cause they will "share" thar var... AND that var will
remain set at the SAME value it was at when the last instance of the function ended.
And accssing GLOBAL vars is no faster OR slower than local ones.


If you truly want to scorch you brain with optimising at the expence of readability,
look at ALL the VEC_??? functions being used. If you check the manual, you
will find many of them show the actual CORE algorithms they use.
Replace those VEC_??? calls with its intrinsic algorithm and you WILL gain speed.
Also, in some situations you may see you dont actually need the WHOLE algorithm,
and so you can leave some off. More time saved.
BUT, some of the VEC_??? commands do have some error-protection you will lose,
and others have data type-casting 'adptatability' that you will lose.
And none of this is mentioned in the manual, so its hard to say what you are
losing, and you aint going to be gaining THAT much...
Oh... and the 'readability' of you script will go to hell, AND you will find it
hard going to find people willing to help debug something like that... let alone able...

And another thing to think about.. Youve spent DAYS generating the code,
and spent WEEKS debugging the bastard...
And NOW you want to take your pretty tested code and butcher it into an
un-recognisable mess that will need de-bugging ALL OVER AGAIN!! And this time
most of the code will be un-intelligble algebraic gibberish.
And all to gain 3 or 4 FPS?? At best?? Nuts! IMHO.

But ... each to their own.