GolangのReflectionは遅いのか？

Posted at 2025-01-31

なぜリフレクションが必要なのか？

まず、リフレクションがもたらす利点を理解する必要があります。もし何の利点ももたらさないのであれば、実際にはそれを使用する必要がなく、パフォーマンスへの影響も心配する必要はありません。

Go言語におけるリフレクションの実装原理

Go言語は構文要素が少なく、設計がシンプルなため、特に強力な表現力を持っていません。しかし、Go言語のreflectパッケージはその構文的な欠点を補うことができます。リフレクションは重複したコーディング作業を減らすことができ、ツールキットはリフレクションを使用して異なる構造体の入力パラメータを処理します。

リフレクションを使用して構造体が空であるかどうかを判断する

ビジネスシナリオ

このように、入力された構造体が空の場合、SQLを連結することなく直接返すことができ、その結果、全テーブルスキャンや低速なSQLを回避することができます。

リフレクションを使用しない実装

リフレクションを使用しない場合、構造体が空であるかどうかを判断する必要があるとき、各フィールドを1つずつチェックする必要があります。以下に実装例を示します：

type aStruct struct {
    Name string
    Male string
}

func (s *aStruct) IsEmpty() bool {
    return s.Male == "" && s.Name == ""
}

type complexSt struct {
    A        aStruct
    S        []string
    IntValue int
}

func (c *complexSt) IsEmpty() bool {
    return c.A.IsEmpty() && len(c.S) == 0 && c.IntValue == 0
}

この時、新しい構造体が空であるかどうかを判断する必要がある場合は、各フィールドをチェックする対応するメソッドを実装する必要があります。

リフレクションを使用する実装

リフレクションを使用して実装する場合は、「Golang Empty Struct Judgment」を参照することができます。この時、対応する構造体を渡すだけで、対応するデータが空であるかどうかを取得することができ、繰り返しの実装が不要になります。

パフォーマンス比較

func BenchmarkReflectIsStructEmpty(b *testing.B) {
    s := complexSt{
        A:        aStruct{},
        S:        make([]string, 0),
        IntValue: 0,
    }
    for i := 0; i < b.N; i++ {
        IsStructEmpty(s)
    }
}

func BenchmarkNormalIsStructEmpty(b *testing.B) {
    s := complexSt{
        A:        aStruct{},
        S:        make([]string, 0),
        IntValue: 0,
    }
    for i := 0; i < b.N; i++ {
        s.IsEmpty()
    }
}

パフォーマンステストの実行

# -benchmem を使用して、1回の操作あたりのメモリ割り当て数を表示
# -benchtime=3s を使用して、実行時間を3秒に指定。一般的に、1秒、3秒、5秒で得られる結果は似ています。パフォーマンスが低い場合は、実行時間が長いほど、平均パフォーマンス値が正確になります。
# -count=3 を使用して、実行回数を指定。複数回の実行で精度を保証できます。
# -cpu n を使用して、CPUコア数を指定。一般的に、CPUコア数を増やすとパフォーマンスが向上しますが、必ずしも正の相関関係ではありません。コア数が多いとコンテキストスイッチに影響が出るため、IO集約型アプリケーションかCPU集約型アプリケーションかによります。マルチゴルーチンテストで比較を行うことができます。
go test -bench="." -benchmem -cpuprofile=cpu_profile.out -memprofile=mem_profile.out -benchtime=3s -count=3.

実行結果

BenchmarkReflectIsStructEmpty-16                 8127797               493 ns/op             112 B/op          7 allocs/op
BenchmarkReflectIsStructEmpty-16                 6139068               540 ns/op             112 B/op          7 allocs/op
BenchmarkReflectIsStructEmpty-16                 7282296               465 ns/op             112 B/op          7 allocs/op
BenchmarkNormalIsStructEmpty-16                 1000000000               0.272 ns/op           0 B/op          0 allocs/op
BenchmarkNormalIsStructEmpty-16                 1000000000               0.285 ns/op           0 B/op          0 allocs/op
BenchmarkNormalIsStructEmpty-16                 1000000000               0.260 ns/op           0 B/op          0 allocs/op

結果分析

結果フィールドの意味：

結果項目	意味
BenchmarkReflectIsStructEmpty - 16	BenchmarkReflectIsStructEmpty はテスト関数の名前で、 - 16 は GOMAXPROCS（スレッド数）の値が16であることを示します
2899022	合計2899022回の実行が行われました
401 ns/op	1回の操作あたり平均401ナノ秒がかかったことを示します
112 B/op	1回の操作あたり112バイトのメモリが割り当てられたことを示します
7 allocs/op	メモリが7回割り当てられたことを示します

リフレクションによる各操作の時間消費は、直接判断する場合の約1000倍であり、また7回の追加メモリ割り当てももたらし、1回あたり112バイト増加します。全体的に、直接操作に比べてパフォーマンスが大幅に低下します。

リフレクションを使用して同名の構造体フィールドをコピーする

リフレクションを使用しない実装

実際のビジネスインターフェースでは、DTOとVOの間でデータを変換する必要がよくあり、その大半は同名のフィールドのコピーです。この時、リフレクションを使用しない場合、各フィールドをコピーする必要があり、新しい構造体をコピーする必要があるとき、以下のようにnewメソッドの記述を繰り返す必要があり、多くの重複作業をもたらします：

type aStruct struct {
    Name string
    Male string
}

type aStructCopy struct {
    Name string
    Male string
}

func newAStructCopyFromAStruct(a *aStruct) *aStructCopy {
    return &aStructCopy{
        Name: a.Name,
        Male: a.Male,
    }
}

リフレクションを使用する実装

リフレクションを使用して構造体をコピーする場合、新しい構造体をコピーする必要があるとき、構造体ポインタを渡すだけで同名のフィールドをコピーすることができます。以下に実装例を示します：

func CopyIntersectionStruct(src, dst interface{}) {
    sElement := reflect.ValueOf(src).Elem()
    dElement := reflect.ValueOf(dst).Elem()
    for i := 0; i < dElement.NumField(); i++ {
        dField := dElement.Type().Field(i)
        sValue := sElement.FieldByName(dField.Name)
        if!sValue.IsValid() {
            continue
        }
        value := dElement.Field(i)
        value.Set(sValue)
    }
}

パフォーマンス比較

func BenchmarkCopyIntersectionStruct(b *testing.B) {
    a := &aStruct{
        Name: "test",
        Male: "test",
    }
    for i := 0; i < b.N; i++ {
        var ac aStructCopy
        CopyIntersectionStruct(a, &ac)
    }
}

func BenchmarkNormalCopyIntersectionStruct(b *testing.B) {
    a := &aStruct{
        Name: "test",
        Male: "test",
    }
    for i := 0; i < b.N; i++ {
        newAStructCopyFromAStruct(a)
    }
}

パフォーマンステストの実行

go test -bench="." -benchmem -cpuprofile=cpu_profile.out -memprofile=mem_profile.out -benchtime=3s -count=3.

実行結果

BenchmarkCopyIntersectionStruct-16              10789202               352 ns/op              64 B/op          5 allocs/op
BenchmarkCopyIntersectionStruct-16              10877558               304 ns/op              64 B/op          5 allocs/op
BenchmarkCopyIntersectionStruct-16              10167404               322 ns/op              64 B/op          5 allocs/op
BenchmarkNormalCopyIntersectionStruct-16        1000000000               0.277 ns/op           0 B/op          0 allocs/op
BenchmarkNormalCopyIntersectionStruct-16        1000000000               0.270 ns/op           0 B/op          0 allocs/op
BenchmarkNormalCopyIntersectionStruct-16        1000000000               0.259 ns/op           0 B/op          0 allocs/op

上記の最初の実行結果と同様に、リフレクションの時間消費は依然としてリフレクションを使用しない場合の1000倍であり、メモリ割り当ても1回あたり64バイト増加します。実際のビジネスシナリオでは、複数のリフレクションが組み合わされることがあります。実際のパフォーマンスをテストする必要がある場合は、独自のBenchmarkTestを書くことができます。フレームグラフを比較することで、実行時間の割合をより明確に表示することができます。

結論

ビジネスインターフェースでは、インターフェース応答が10msで、リフレクションメソッドの平均操作が400ナノ秒で、約64 - 112バイトの追加メモリ割り当てが発生すると仮定します。

1ms [ミリ秒] = 1000μs [マイクロ秒]=1000 * 1000ns [ナノ秒]
1MB = 1024KB = 1024 * 1024 B

インターフェースがリンク内で1000回のリフレクション操作を行う場合、1回の操作でインターフェースの遅延が約0.4ms増加します。一般的に、1つの要求内のミドルウェアやビジネス操作の数はこの数に達することはめったにありませんので、応答時間への影響は基本的に無視できます。実際のビジネスでは、より多くの損失はメモリコピーとネットワークIOにあります。

ただし、リフレクションにはコーディング上の本当の問題もあります。通常のビジネスコードよりも保守と理解が難しいです。したがって、使用する際には慎重に検討する必要があり、コードの複雑さを絶えず増やすことになる過度の使用を避ける必要があります。