It was determined that Math.floor and Math.ceil take up a lot of cpu time for some tests (see attached Grid.fx).

Dumping the email exchange with Jim and Rich:

  Ok, I put that optimization in, and promptly ceil() became #1 in the profiler.
  So hacked it to just returning (int)(f+0.5) for positives (for the sake of the experiment).

  The cpu usage for Grid dropped from 95-100% to <50%, so this looks like something definitely worth pursuing.

  Thanks,
    Dmitri


Jim Graham wrote:
> Hmmm...
>
> http://forums.sun.com/thread.jspa?threadID=5369374&start=0&tstart=0
>
> If we think negatives are rare then a compromise might be:
>
> i = (f < 0) ? ((int) Math.floor(f)) : ((int) f);
>
> ...jim
>
> Dmitri Trembovetski wrote:
>>
>>
>> Hi Jim,
>>
>> Jim Graham wrote:
>>> Hi Dmitri,
>>>
>>> I just added some Math.floor() calls to NodeEffectInput and as I was
>>
>> Yeah, I noticed =)
>>
>>> doing it I was thinking about an email that you sent out a few days ago about this showing up in profiles. Did you ever get to the bottom of that?
>>
>> Well, I only got to the level of showing that it was floor() that was taking the cpu.
>>
>>> Also, in your profile you showed stack traces of the StrictMath package. I thought that the runtime only used that if you specified a command line option to request it, no? Or do we need to specify an option to "not be strict"?
>>
>> Hmm. This is from java6 Math.java:
>> public static double floor(double a) {
>> return StrictMath.floor(a); // default impl. delegates to StrictMath
>> }
>>
>> And StrictMath.floor(a) is a native method.
>>
>> Pretty much all Math methods go through StrictMath. (looks like that's been the case at least since 1.4).
>>
>>> In the case of the code I was adding, I don't think the performance would hurt us, but it sounded like the code you were using was banging on the floor() function much more...
>>
>> The code I pointed at in RT-5835 is executed for every rendered rectangle.
>>