Jump to content

  • Log In with Google      Sign In   
  • Create Account


#ActualSchrompf

Posted 20 February 2013 - 03:55 AM

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.


#2Schrompf

Posted 20 February 2013 - 03:53 AM

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 need to be garbage-collected somewhere in the future? And you still worry about the performance of sin()? I don't get it.


#1Schrompf

Posted 20 February 2013 - 03:48 AM

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.


PARTNERS