2

私のコードでは多くのリフレクションルックアップを行っているので、なんとかしてそれを改善しようとしていました。

これは私のjniセッターメソッドのサンプルです：

JNIEXPORT jobject JNICALL 
Java_org_orman_mapper_Model_fieldSetFloat(JNIEnv * env, jobject  obj, jobject model, jstring field_name, jstring field_type, jfloat value, jclass clazz)
{
    const char* utf_string_name = (*env)->GetStringUTFChars (env, field_name, 0);
    const char* utf_string_type = (*env)->GetStringUTFChars (env, field_type, 0);

    jfieldID id = (*env)->GetFieldID(env, clazz, utf_string_name, utf_string_type);
    (*env)->SetFloatField(env, model, id, value);
    return model;
}

のような呼び出しの本質はSetFloatField、Javaのセキュリティチェックをスキップしますか？

パフォーマンスの向上には気づいていません。

4

1 に答える 1

6

jniで反射性能を向上させることは可能ですか？

おそらく、少し。ただし、「不要な」アクセスチェックを排除することはできますが、オブジェクトの内部にアクセスするためにJNI呼び出しを行う必要があるため、その一部が失われます。対照的に、リフレクションメソッドとその呼び出しシーケンスの実装は、通常のJNIメソッドでは利用できない方法で最適化される場合があります。

（たとえば、プラットフォームに依存しないJNI APIを使用するのではなく、関連するデータ構造に直接アクセスするように実装できます。または、JITコンパイラは、一部の「固有の」ネイティブメソッドへのネイティブメソッド呼び出しを特殊なケースとして扱い、より高速に使用する場合があります。シーケンスの呼び出し。これはすべて架空のものであることに注意してください...ただし、一部のJVMでは、一部のコアメソッドのネイティブ実装に特別な処理が施され、高速化されています。）

しかし、私のアドバイスは、反射コードを通常の非反射Javaコードに置き換えると、手書きのコードであれ、ソースとして生成されてコンパイルされたコードであれ、はるかに優れたパフォーマンスが得られることです。 、またはバイトコードとして生成されるコード。バイトコードを取得すると、JITコンパイラーは、リフレクションまたはJNIを使​​用するよりもはるかに高速な最適化されたネイティブコードを生成できるようになります。

したがって、リフレクションをJNIコード（およびそれに関連する問題）に置き換えるのではなく、純粋なバイトコードを使用するものに置き換えてください。

于 2012-09-18T15:15:43.117 に答える