I still wonder why you'd even bother to optimize this. 50 calls per frame? Incredible! Make that 500k calls and you'd need to start worrying. But even then the first thing you should do is to MEASURE. Stop guessing that something might be a problem, start measuring what actually consumes the most processing time. I'd wager that sin()/cos() won't even show up on the list.

Also: packing a double into an Java object to be able to pass it around by reference? Your math does really create thousands of small objects every frame, and most but not all of them are outscoped at the end of the frame. The garbage collector will love you.

^This. In Java is very, very easy allocate thousands of new objects without noticing (a common example is making tons of String objects). Allocation time by itself wont be noticeable (unless you're allocating many complex objects, it those cases it is recommended that you reuse such objects where makes sense), but the allocation time + garbage collection time can build up and be a problem eventually.

Though I'm not sure if he meant a wrapper coded by him or the boxed Double

By looking around I'm inclined to say that Java has earned its reputation of being "slow" because is very easy and convenient to allocate new objects around at every single line of code, inside loops (worst), at the "return" of all methods (not so bad), etc.

^This. In Java is very, very easy allocate thousands of new objects without noticing (a common example is making tons of String objects). Allocation time by itself wont be noticeable (unless you're allocating many complex objects, it those cases it is recommended that you reuse such objects where makes sense), but the allocation time + garbage collection time can build up and be a problem eventually.

Though I'm not sure if he meant a wrapper coded by him or the boxed Double

By looking around I'm inclined to say that Java has earned its reputation of being "slow" because is very easy and convenient to allocate new objects around at every single line of code, inside loops (worst), at the "return" of all methods (not so bad), etc.

Java has a lot of problems here...

basically, it is fairly easy to write code which starts spewing garbage at high speeds, and internally (in its libraries) makes considerable use of operations which solve problems simply by creating new objects only to discard them again, coupled with a lack of compound value-types, limited ability to perform lifetime inference, lack of reference arguments, ... leaving "new" as mostly the primary solution to "pretty much everything".

writing code which is more conservative with memory in Java is possible, just it requires care and isn't usually really all that pretty.

usually the problem is mostly not obvious as the JVM also has a pretty fast GC (so, the GC may run once every few seconds, and largely escape notice).

(I still though much prefer other more sanely designed languages...).

now as for sin/cos performance:

usually this becomes more relevant when these are being used many millions of times per second or similar.

now as for sin/cos performance:

usually this becomes more relevant when these are being used many millions of times per second or similar.

At which point one should step back and think hard about why so many sin/cos evaluations are needed. Geometric computations made using the language of vectors and matrices can very often be performed without any evaluations of trigonometric functions at all.

pretty much...

it could also be taken as evidence that micro-optimizing sin/cos is probably premature optimization.

I have more often ran across this being an issue with sqrt, and generally this being because sqrt is needed for things like vector length and renormalization, which are typically much more common IME.