It seems that this patch has no reviewers specified. If you are unsure who can review your patch, please check this wiki page and see if anyone can be added: https://phab.enlightenment.org/w/maintainers_reviewers/
What i mean is: sqrt(a²+b²) / sqrt(2) can be written as sqrt(a²/2+b²/2).
Additionally if you cast a² and b² to a int, the compiler can reduce this to a shift, eliminating floating point division or mul operations totally, making this even lightweighter than before.
Even more micro optimizing you could write the whole thing as: sqrt((a*a)/2 + (b*b)/2) leaving out a func call, or instruction to floating point pow. This way things stay within none-floating-point op's making it less calc intensive.
more important: at normal optimizations (-O2 is pretty normal for production builds or even -O3), does this actually remove a sqrt() function or is the compiler already detecting a sqrt with a constant and pre-calculating it? :) because... looking at the asm output of the compiler.. it figures out that its a constant... even at -O0. it still optimizes it to a constant. compare the asm output of:
printf("hello %1.1f\n", sqrt(2.0));
printf("hello %1.1f\n", M_SQRT1_2);
:) so like the other patch i just said no to... does this make the code easier or harder to read? i could argue its a little harder to read with zero benefits. little literally the same identical asm output... :) sam thing as before - look for things that actually optimize... :)
@raster the problem with sqrt calls is that they do not get replaced in *all* compilers, clang on macos is not capable of doing that (i have no idea why). gcc on my raspi is also not doing it here ...
The reason why i think this has potential is that we can completely get rid of the call, simply by throwing math at it, making it a simple full number op.
First : this is very small impact.
Second : you are talking only about specific compiler(s) , or maybe most of them, but this is not general thing everywhere.