Hi Clemens. > I've only followed your discussion with Jim but skipped all the > in-depth discussion. > From my prior experiences usually JNI is not woth the trouble, if > you don't have a serious reason why using native code would have > advantages (like the possibility of using SIMD or when value-types > would be a huge benefit), it has its own performance pitfalls > especially if the workload is small and things like Get*ArrayCritical > cause scalability problems because they have to lock the GC.
Well, Jim Graham said that a native version of the engine still runs a lot faster than the version with all my changes. That's why I thought it would be a good idea. Also, when not doing antialiasing we usually feed paths to native consumers, so I thought if pisces used JNI, we could reduce the java->C transitions five fold. But then I realized that with antialiasing the opposite would happen, so I'm not sure whether JNI is a good idea. > Have you had a look at the Netbeans profiler? It supports sampling > based testing to keep the influence of the profiler at a minimum. No, I don't use netbeans - it doesn't render underscores properly (although I think this is an openjdk bug). I'll try it out. > Thanks for working on this! It's been fun. Regards, Denis. ----- "Clemens Eisserer" <linuxhi...@gmail.com> wrote: > Hi Denis, > > > It's not obvious to me why this happened, so I think now I will put > > this type of optimization aside and convert to JNI, > > > > where profiling > > will be easier (for me - I haven't been able to make OProfile work > > for java yet). > > - Clemens
