3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

自動実装プロパティのget/setの速さについて調べた話

Posted at

#はじめに
自動実装プロパティのget/setの速さってフィールドの読み書きと比べてどうなんだろう?」と思ったので簡単に調べました。

#環境

Windows 8.1 (変なの使っててスミマセン)
Microsoft Visual Studio Community 2019 Version 16.4.3
.Net Framework 4.7.2
ILSpy version 5.0.2.5153
BenchmarkDotNet v0.12.0

#プロパティの操作 ≒ メソッド呼び出し
 プロパティに対してはフィールドのようにアクセスできますが、実際にはメソッドの呼び出しが行われます。フィールドの場合はメソッドの呼び出しは行われません。(なので私はフィールドへの読み書きの方が自動実装プロパティのget/setより少し速いだろうと思っていました)

 プロパティに対する読み書きがメソッド呼び出しになっていることを確かめてみましょう。下のコードをビルドし、ILのコードを確認します。

using System;

namespace ConsoleApp11
{
    public class Person
    {
        /// <summary>
        /// プロパティ
        /// </summary>
        public string Name { get; set; }

        /// <summary>
        /// フィールド (パブリックフィールドはホントは使っちゃダメだぞ)
        /// </summary>
        public int Age;
    }

    class Program
    {
        static void Main(string[] args)
        {
            var p = new Person() { Name = "taro", Age = 8};

            Console.WriteLine(p.Name);
            Console.WriteLine(p.Age);
        }
    }
}

上のコードをビルドして作ったexeファイルをILSpyで開くとILのコードを見ることができます。Nameプロパティへの読み書きはget_Nameとset_Nameになっていることが分かります。Ageフィールドへの読み書きはstfldldfldという命令になっています。
逆コンパイル1.PNG

#インライン化
 プロパティへの読み書きはメソッド呼び出しとなり、フィールドへの読み書きはメモリの操作になることが分かりました。メソッド呼び出しを行う分、プロパティの方がフィールドよりも遅くなりそうな気がしますが、ILがネイティブコードに変換される過程がまだ残っています。

 プログラムを実行するとき、ILはランタイムによってネイティブコードに変換されます(JITコンパイル)。そしてこのときに、メソッド呼び出しのコードが呼び出し先のメソッド中にある処理に置き換えられることがあります(インライン化)。 

 インライン化が行われる条件について正確なことは分からないのですが、自動実装プロパティのget/setのように、処理内容が単純な場合はインライン化されるようです。

 コードを使って少し実験してみます。まずはインライン化を行わない場合です。Nameプロパティに[MethodImpl(MethodImplOptions.NoInlining)]属性を付けてインライン化を抑制します。

public class Person
{
    public string Name
    {
        [MethodImpl(MethodImplOptions.NoInlining)]
        get;
        [MethodImpl(MethodImplOptions.NoInlining)]
        set;
    }
    public int Age;
}

NameプロパティのsetのJITコンパイル後の内コードを見てみます。プロパティに値を代入する箇所にブレークポイントを置き、処理が止まったら逆アセンブリウィンドウを開きます。逆アセンブリウィンドウ上でもC#のコードのようにステップ実行できるのでブレークポイントの後ろにあるcall命令のところまで処理を進めます。

逆アセンブル.PNG

call命令の直前まで来たらステップインします。
逆アセンブル2.PNG

ステップインするとsetメソッドの中に入れますが、入った先にもう一つcall命令があります。2つ目のcall命令を実行するとプロパティの値が書き変わります。ただ、2つ目のcall命令のジャンプ先には逆アセンブリウィンドウからの操作では進めず、これ以上のことは分かりませんでした。(理由はよく分からない)

 次にインライン化を有効にした場合を見てみます。Nameプロパティに付ける属性の内容を変えます。

public class Person
{
    public string Name
    {
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        get;
        [MethodImpl(MethodImplOptions.AggressiveInlining)]
        set;
    }
    public int Age;
}

先ほどと同じようにNameプロパティに値を設定するところで処理を止めて様子を見てみます。
逆アセンブル3.PNG

call 7467EC30は先ほどのインライン化させない場合のときの、2つ目のcall命令の内容と一致しています。また、1つ目のcall命令は見当たらなくなりました。恐らくですがインライン化により削除されたのではないかと思います。

#ベンチマーク
インライン化の雰囲気を感じられたところで、プロパティとフィールドに対する読み書きの時間を比べてみようと思います。ベンチマークにはBenchmarkDotNet を使いました。以下のコードをリリースビルドし、実行します。

using System.Linq;
using System.Runtime.CompilerServices;
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;

namespace ConsoleApp10
{
    public class PropertyVsField
    {
        public int AggressiveInlining
        {
            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            get;

            [MethodImpl(MethodImplOptions.AggressiveInlining)]
            set;
        }

        public int NoInlining
        {
            [MethodImpl(MethodImplOptions.NoInlining)]
            get;

            [MethodImpl(MethodImplOptions.NoInlining)]
            set;
        }

        public int Default
        {
            get;
            set;
        }

        public int Field;
    }

    public class PropBenchmark
    {
        public PropertyVsField propVsField = new PropertyVsField()
        {
            AggressiveInlining = 42,
            NoInlining = 42,
            Default = 42,
            Field = 42
        };

        [Benchmark]
        public int AggressiveInlining()
        {
            int v = 0;
            foreach (var _ in Enumerable.Range(1, 10))
            {
                v += this.propVsField.AggressiveInlining;
            }

            return v;
        }

        [Benchmark]
        public int NoInlining()
        {
            int v = 0;
            foreach (var _ in Enumerable.Range(1, 10))
            {
                v += this.propVsField.NoInlining;
            }

            return v;
        }

        [Benchmark]
        public int Default()
        {
            int v = 0;
            foreach (var _ in Enumerable.Range(1, 10))
            {
                v += this.propVsField.AggressiveInlining;
            }

            return v;
        }

        [Benchmark]
        public int Field()
        {
            int v = 0;
            foreach (var _ in Enumerable.Range(1, 10))
            {
                v += this.propVsField.AggressiveInlining;
            }

            return v;
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            var summary = BenchmarkRunner.Run<PropBenchmark>();
        }
    }
}

※1回のgetの呼び出しだと処理時間が短すぎて差が確認できなかったのでforeachで回しています
※getとsetで結果に違いが出るとは考えにくかったのでgetだけ調べました。(値の設定はフィールドの方が速いけど、参照はプロパティの方が速いとかそんなことにはならないだろうと思った。setではなくgetにした理由は特にないです。)

実行結果は私の環境ではこんな感じになりました。
ベンチマーク.PNG
NoInlining以外は大体同じくらいの時間(Mean)になっているので、AggressiveInliningを指定しなくてもインライン化が行われてフィールドへの操作と同じくらいの効率でプロパティへのアクセスができていることが分かります。

#参考
自動実装するプロパティ (C# プログラミング ガイド)
フィールド (C# プログラミング ガイド)
More Effective C# 6.0/7.0 項目1 アクセス可能なデータメンバーの代わりにプロパティを使おう
++C++; [フレームワーク / 実行環境] JITコンパイル
++C++; [構造化] [雑記] インライン化
Visual Studio デバッガーでの逆アセンブリ コードの表示
ILSpy
BenchmarkDotNet

3
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
3

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?