Roman Kennke wrote:
>>> The problem is that the program is spending almost all of the time
>>> generating stack traces, millions and millions of them.
>> And one reason for that is pointless class lookups in
>> the GTK peer code.
>>
>> Look at this:
>>
>> Java_gnu_java_awt_peer_gtk_FreetypeGlyphVector_getKerning
>> (JNIEnv *env, jobject obj __attribute__((unused)), jint rightGlyph, jint leftGlyph, jlong fnt)
>> {
>> ...
>>
>> cls = (*env)->FindClass (env, "java/awt/geom/Point2D$Double");
>> method = (*env)->GetMethodID (env, cls, "<init>", "(DD)V");
>> return (*env)->NewObjectA(env, cls, method, values);
>> }
>>
>> Now, this method only returns a pair of points, and it would have been
>> trivial to pass a 2-element array into it, fill, with x and y, and
>> return the same array. But no, we do a class lookup on
>> java/awt/geom/Point2D$Double and call its constructor with two
>> double values.
>
> Or we could cache the MIDs and FIDs, like is recommended in all good JNI
> books.
Sure, but it would be far slower. Why would you want to call
constructors in the middle of a critical loop?
Andrew.
