この投稿は、発行するのに十分なカルマを持っていないhabrayuzer mstyuraのリクエストで発行されています。 この記事が気に入ったら、著者に感謝し、カルマを手伝ってください。
重要な種類の包装/開梱のトピックに関するミニスタディの結果をKhabrosocommunityと共有したいと思います。 このトピックを書くきっかけとなったのは、リヒター
の本
「C＃を介したCLR」と
R＃そのものです。 私の意見では、後者は私のコードに「不正な」コメントを与えました。
問題は何ですか？
実際、私はこのようにかなり標準的なコードを書いた
string str = "habrahabr" ;
int val = 0;
var resultString = str + val.ToString();
* This source code was highlighted with Source Code Highlighter .
Resharperは、重要な変数valでのToString（）メソッドの明示的な呼び出しを好まなかったが、この場合、書いたとおりに実行する方が確実であることがわかっているときに何をすべきかを彼が教えてくれることは当然嫌いだった。 誰が正しいか見てみましょう。 まず、R＃で提案されているコードを実行したときにどのような操作が発生するかを考えておくことをお勧めします。
string str = "habrahabr" ;
int val = 0;
var resultString = str + val;
* This source code was highlighted with Source Code Highlighter .
最後の行には、異なるタイプの2つの変数を追加する操作があり、その結果は文字列になります。 変数はさまざまなタイプであるため、
文字列 Systemメソッドの次のバージョンが呼び出されます。
文字列 .Concat（
オブジェクト 、
オブジェクト ）。 つまり 実際、プログラムコードは次のようになります
string str = "habrahabr" ;
int val = 0;
var resultString = System. String .Concat(str, val);
* This source code was highlighted with Source Code Highlighter .
str（文字列は参照型）およびval（整数は重要な型）パラメーターを渡すと、2番目のパラメーターに対してパッケージング操作が実行されます。これは、重要なint型をメソッドに渡そうとしているため、参照オブジェクトを予期しているためです。
パッケージとは何ですか？
正確に定義するために、Richter
の本
「CLR via c＃」に注目しました 。 だから：
ボクシングとは、重要な型を参照に変換することです。 重要なタイプのインスタンスをパッケージ化すると、次のことが発生します。
1.マネージヒープでは、メモリが割り当てられます。 そのボリュームは、有効なタイプの長さと、マネージヒープ内のすべてのオブジェクトに必要な2つの追加メンバー（オブジェクトタイプへのポインターとSyncBlockIndexインデックス）によって決まります。
2.重要なタイプのフィールドは、ヒープ上に割り当てられたメモリにコピーされます。
3.オブジェクトのアドレスが返されます。 このアドレスはオブジェクトへの参照です。 意味のある型が参照型になりました。
まだToString（）を呼び出す場合
System.String.Concat（）メソッドに渡す前にval変数でToString（）メソッドを呼び出すと、コンパイラは
文字列 System
文字列連結メソッドの次のバージョンを選択します。
String .Concat（
string 、
string ）、なぜなら 同じ参照タイプ
文字列のオブジェクトが入力に送られます。 この場合、パッキング操作は実行されません。これは、ヒープ上の重要な型にメモリを割り当て、重要な型の元の変数のすべてのバイトをそこにコピーし、割り当てられたメモリ位置へのポインタを返すことを意味します。
何にコンパイルしますか？
ToString（）を呼び出さずに
- .locals init（[0] string str、[1] int32 val、[2] string resultString）
- IL_0000：nop
- IL_0001：ldstr "habrahabr"
- IL_0006：stloc.0
- IL_0007：ldc.i4.0
- IL_0008：stloc.1
- IL_0009：ldloc.0
- IL_000a：ldloc.1
- IL_000b： ボックス [mscorlib]システム。 Int32
- IL_0010： 文字列 [mscorlib]システムを呼び出します 。 文字列 ::連結（ オブジェクト 、 オブジェクト ）
- IL_0015：stloc.2
*このソースコードは、 ソースコードハイライターで強調表示されました。
ToString（）を呼び出して
- .locals init（[0] string str、[1] int32 val、[2] string resultString）
- IL_0000：nop
- IL_0001：ldstr "habrahabr"
- IL_0006：stloc.0
- IL_0007：ldc.i4.0
- IL_0008：stloc.1
- IL_0009：ldloc.0
- IL_000a：ldloca.s val
- IL_000c：呼び出しインスタンス文字列 [mscorlib]システム。 Int32 :: ToString（）
- IL_0011：呼び出し文字列 [mscorlib]システム。 文字列 ::連結（ string 、 string ）
- IL_0016：stloc.2
*このソースコードは、 ソースコードハイライターで強調表示されました。
与えられたILコードの主な違いは、ボックス操作です。これは、パッキング操作を実行します。逆のアンパック命令は、アンボックス命令に対応します。ここでは考慮しません。
パフォーマンスへの影響
明らかに、上記のコードのパフォーマンスを判断することは困難です。なぜなら、 単一の梱包作業で十分に高速です。 次のループを書く
for ( int i = 0; i < 10000000; i++)
{
var s = "habrahabr" + i;
}
* This source code was highlighted with Source Code Highlighter .
ランタイムを測定するには、System.Diagnostics名前空間の
Stopwatchクラスを使用します。 DateTimeを使用するよりもはるかに正確な結果が得られます。 たとえば、私のマシンでは、DateTime.Nowの2つを連続して呼び出すと、差00：00：00.0010010000が得られ、
ストップウォッチの即時開始と停止は00：00：00.0000015になります。 肉眼でのWindowsの違い。
パッケージング操作をテストする最終コードは次のようになります
namespace BoxingTraining
{
using System;
using System.Diagnostics;
public class Program
{
private static void Main()
{
var time = Stopwatch.StartNew();
for ( int i = 0; i < 10000000; i++)
{
var s = "habrahabr" + i;
}
Console .WriteLine(time.Elapsed.ToString());
}
}
}
* This source code was highlighted with Source Code Highlighter .
以下は、int値（4バイト）をパックするときに上記のコードを実行した結果の表です。
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0,0324421 | 0,0314838 | 0,0009583 | 3,043788 |
| 1,000,000 | 0.3329810 | 0.2927090 | 0,0402720 | 13,75837 |
| 10,000,000 | 3,5344330 | 3.2425843 | 0.2918487 | 9,000497 |
| 1億 | 35.9022937 | 35,4208982 | 0.4813955 | 1.359072 |
ご覧のように、結果は、パッケージを支持するものではありませんが、一度に見えるほどひどいものではありません。 さらに、型サイズ（占有メモリの値）も結果に影響を与える可能性があると想定できます。次のステップは、char型、byte型、ある種の重い重み付き構造の1つの値をパックすることです。
重要なタイプの変数のパッケージングをテストするためのコード。
namespace boxingTraining
{
using System;
using System.Diagnostics;
public class Program
{
private static void Main()
{
var time = Stopwatch.StartNew();
for ( int i = 0; i < 1000000; i++)
{
var s = "habrahabr" + ;
}
Console .WriteLine(time.Elapsed.ToString());
}
}
}
* This source code was highlighted with Source Code Highlighter .
charの結果のテーブル（2バイト）
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0,0120120 | 0,0080280 | 0,003984 | 49,62631 |
| 1,000,000 | 0.0925545 | 0,0738690 | 0.0186855 | 25,29546 |
| 10,000,000 | 0.8949694 | 0.7298598 | 0.1651096 | 22.6221 |
| 1億 | 9,1908556 | 6,9977169 | 2,1931387 | 31,34077 |
バイト（1バイト）の結果テーブル
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0.0264363 | 0,0242211 | 0.0022152 | 9,145745 |
| 1,000,000 | 0.2600672 | 0.2304188 | 0,0296484 | 12,86718 |
| 10,000,000 | 2,5563460 | 2,2713021 | 0.2850439 | 12,5498 |
| 1億 | 25,1847944 | 22,3063352 | 2,8784592 | 12,90422 |
少し叙情的な余談。 このトピックを書いてこの点に到達したとき、この記事を書くときに相談したAldanko
habrayuzerは 、この状況での動作を確認し、内部タイプデバイスの影響を調べるために、より標準的なタイプのテストを強く推奨しましたパッキング操作。
次のタイプのSystem.Int16（2バイト）、System.Int64（8バイト）、System.Single（4バイト）、System.Double（8バイト）、およびSystem.Decimal（16バイト）をテストします。
System.Int16の場合
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0,0268269 | 0,0252753 | 0,001552 | 6.1388 |
| 1,000,000 | 0.2508171 | 0.2283134 | 0,022504 | 9.856496 |
| 10,000,000 | 2,5840173 | 2,2771103 | 0.306907 | 13,47792 |
| 1億 | 25.5575014 | 22,6322024 | 2,925299 | 12.92538 |
System.Int64の場合
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0,0313252 | 0,0261576 | 0.005168 | 19,75564 |
| 1,000,000 | 0.2730405 | 0.2520212 | 0,021019 | 8,34029 |
| 10,000,000 | 2,7573422 | 2.3089744 | 0.448368 | 19,41848 |
| 1億 | 26,6876964 | 23.3565123 | 3.331184 | 14.26234 |
System.Singleの場合
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0,0488271 | 0.0435174 | 0.00531 | 12,20133 |
| 1,000,000 | 0.4585808 | 0.4277303 | 0,030851 | 7,212606 |
| 10,000,000 | 4,5009957 | 4,2313242 | 0.269671 | 6.373218 |
| 1億 | 44,9906154 | 42,5702807 | 2,420335 | 5,685503 |
System.Doubleの場合
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0.0477293 | 0,0454006 | 0.002329 | 5,129227 |
| 1,000,000 | 0.4774911 | 0.4507611 | 0,02673 | 5.92997 |
| 10,000,000 | 4.7426156 | 4,5235923 | 0.219023 | 4.8418 |
| 1億 | 47.4816881 | 44.3383082 | 3.14338 | 7.089535 |
System.Decimalの場合
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0.0342277 | 0.0302381 | 0.00399 | 13.19395 |
| 1,000,000 | 0,3082451 | 0.2852763 | 0,022969 | 8.051422 |
| 10,000,000 | 3.0517615 | 2.8142709 | 0.237491 | 8,438797 |
| 1億 | 30.7824241 | 27.8104480 | 2.971976 | 10.68655 |
ご覧のとおり、ToString（）の呼び出しは常に高速です。 原則として、遅くすることはできません。 呼び出されない場合、呼び出されますが、その前に、重要なタイプのオブジェクトはまだパックされます。
カスタム構造のパフォーマンス
私がすでにテストした最も一般的な標準タイプ。 構造を書くときが来ました。 同じhabruiser
Aldankoのアドバイスに基づいて、1600バイトのタイプのフィールド（1バイト）と100フィールドの10進数のフィールド（16バイト）を含む構造を記述します。 最初の構造は次のとおりです
public struct DecimalStruct
{
public decimal Field1;
public decimal Field2;
public decimal Field3;
public decimal Field4;
...
public decimal Field97;
public decimal Field98;
public decimal Field99;
public decimal Field100;
public override string ToString()
{
return "DecimalStruct" ;
}
}
* This source code was highlighted with Source Code Highlighter .
コードの完全版を
ダウンロードできます。1600バイトのフィールド構造
public struct ByteStruct
{
public byte Field1;
public byte Field2;
public byte Field3;
public byte Field4;
...
public byte Field1597;
public byte Field1598;
public byte Field1599;
public byte Field1600;
public override string ToString()
{
return "ByteStruct" ;
}
}
* This source code was highlighted with Source Code Highlighter .
コードの完全版を
ダウンロードできます。したがって、パッケージング操作をテストするコードは次のようになります
namespace boxingTraining
{
using System;
using System.Diagnostics;
public class Program
{
private static void Main()
{
var myStruct = new ByteStruct(); // new DecimalStruct()
var time = Stopwatch.StartNew();
for ( int i = 0; i < 100000; i++)
{
var s = "habrahabr" + myStruct; // myStruct.ToString()
}
Console .WriteLine(time.Elapsed.ToString());
}
}
}
* This source code was highlighted with Source Code Highlighter .
これらの不正行為の目的は、構造の内部構造がパッケージング操作の時間にどのように影響するか、つまり、内部データを管理ヒープにコピーすることです。
その結果。 ByteStructの場合
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0,0553811 | 0,0072760 | 0,048105 | 661.1476 |
| 1,000,000 | 0.5218077 | 0.0591120 | 0.462696 | 782,7441 |
| 10,000,000 | 5,2083878 | 0,5520037 | 4,656384 | 843.5422 |
| 1億 | 61,8142750 | 5,5449448 | 56,26933 | 1014,786 |
DecimalStringの概要
| ループ内の反復回数 | 時間、秒 | 違い、c。 | 賞金、％ |
| ToStringなし（） | ToString（）を使用 |
| 100,000 | 0.0815664 | 0,0068541 | 0,074712 | 1090,038 |
| 1,000,000 | 0.8208648 | 0,0638818 | 0.756983 | 1184,974 |
| 10,000,000 | 6,9349283 | 0.6249309 | 6.309997 | 1009,711 |
| 1億 | 54,7189205 | 6,8453349 | 47.87359 | 699,3608 |
かさばる構造に関する上記のテストからわかるように、ToStringを呼び出すと、最大10倍のゲインが得られます。 これがはっきりと見えていたのは事実です。パッケージ操作を複数回繰り返す必要があります。
結論
このミニスタディからどのような結論を導き出すことができますか？ 少なくとも私にとっては明らかです。 参照型の場合、ToString（）を呼び出してもメリットはなく、文字列操作で使用しても冗長になりますが、重要な型の場合、ToString（）を呼び出す必要があります。 呼び出されると、かなりリソースを消費する操作（パッケージング）を回避します。これは、特定の場合にコードのパフォーマンスを著しく低下させる可能性があります。 さて、R＃は間違っていることが判明し、文字列の連結中の重要な型でのToString（）の呼び出しは冗長であると宣誓しました。 制作することはできませんが、パフォーマンスで支払うことができます。
