[DotNetBook] Stackalloc：忘れられたC＃チーム

この記事では、引き続き一連の記事を公開します。その結果、.NET CLRおよび.NET全般の作業に関する本になります。 本全体がGitHubで利用可能になります（記事の最後のリンク）。



C＃には、かなり興味深い、めったに使用されないキーワードstackalloc



ます。 コード内では非常にまれであるため（ここでは「まれに」という言葉で控えめに言っています。「決して」とは言いません）、その使用の適切な例を見つけるのは非常に難しく、見つけるのはさらに難しくなります。彼と仕事をするのは小さすぎます。 そして、なぜですか？ なぜなら、このコマンドが何をするのかを最終的に決定する人にとって、 stackalloc



ないとstackalloc



より威圧的になるからですstackalloc



のダークサイドは安全でないコードです。 返される結果はマネージポインターではありません。値は、保護されていないメモリのセクションへの通常のポインターです。 さらに、メソッドが動作を完了した後にこのアドレスでレコードを作成すると、メソッドのローカル変数への書き込みを開始するか、メソッドから戻りアドレスを消去することさえできます。その後、アプリケーションはエラーで動作を終了します。 しかし、私たちの仕事は、まさにその隅に侵入し、そこに隠されているものを見つけ出すことです。 そして特に、彼らがこのツールを提供してくれたのは、それが私たちが秘密の熊手を見つけて、そこからそれらを踏むことができるということだけではないことを理解するためです。 それどころか、彼らは私たちにこのツールを提供してくれたので、それを使って本当に高速なソフトウェアを作ることができました。 私はあなたにインスピレーションを与えたいと思いますか？ それでは始めましょう。

ご注意

Habréで公開されている章は更新されておらず、おそらくすでに古いものです。 そのため、最新のテキストについては元に戻してください。

• CLR Book： GitHub、目次
• CLR Book： GitHub、章、「スタックへのメモリの割り当て：stackalloc」へのリンク
• リリース0.5.2の書籍、PDF： GitHubリリース

このキーワードの正しい使用例を見つけるには、まずその作成者であるMicrosoftにアクセスして、その使用方法を確認する必要があります。 これを行うには、 coreclrリポジトリで全文検索を使用して検索します。 キーワード自体のさまざまなテストに加えて、ライブラリコードによるこのキーワードの使用は25を超えないことがわかります。 前のパラグラフで、この小さな数字を見て、私の仕事を閉じなかったときに、読むのをやめないように十分な動機付けをしたいと思います。 正直に言うと、CLRチームは.NET Frameworkチームよりもはるかに先見の明があり、プロフェッショナルであり、何かをしたら、それは私たちに大いに役立つはずです。 そして、これが.NET Frameworkで使用されていない場合...さて、ここで、すべてのエンジニアがこのような強力な最適化ツールがあることを認識しているとは限りません。 そうしないと、その使用量がはるかに大きくなります。



クラスInterop.ReadDir

 unsafe { // s_readBufferSize is zero when the native implementation does not // support reading into a buffer. byte* buffer = stackalloc byte[s_readBufferSize]; InternalDirectoryEntry temp; int ret = ReadDirR(dir.DangerousGetHandle(), buffer, s_readBufferSize, out temp); // We copy data into DirectoryEntry to ensure there are no dangling references. outputEntry = ret == 0 ? new DirectoryEntry() { InodeName = GetDirectoryEntryName(temp), InodeType = temp.InodeType } : default(DirectoryEntry); return ret; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

stackalloc



使用されるstackalloc



とは何ですか？ ご覧のとおり、メモリを割り当てた後、コードはunsafeメソッドに進み、作成されたバッファにデータを入れます。 すなわち 割り当てられたスペースを直接スタックに記録するためのプロットを必要とする安全でないメソッド：動的。 これは、代替案を検討する際に最適な最適化です：Windowsまたは固定（固定）.NETアレイからメモリの一部を要求します。これは、ヒープのロードに加えて、GCをロードして、GCがデータにアクセスしている間、GCが移動しないようにします。 スタックにメモリを割り当てることで、何のリスクもありません。ほぼ瞬時に割り当てが行われ、データを完全に埋めてメソッドを終了できます。 また、メソッドを終了すると、メソッドのスタックフレームも消えます。 一般的に、時間の節約は非常に重要です。



別の例を見てみましょう。



クラスNumber.Formatting :: FormatDecimal

 public static string FormatDecimal( decimal value, ReadOnlySpan<char> format, NumberFormatInfo info) { char fmt = ParseFormatSpecifier(format, out int digits); NumberBuffer number = default; DecimalToNumber(value, ref number); ValueStringBuilder sb; unsafe { char* stackPtr = stackalloc char[CharStackBufferSize]; sb = new ValueStringBuilder(new Span<char>(stackPtr, CharStackBufferSize)); } if (fmt != 0) { NumberToString(ref sb, ref number, fmt, digits, info, isDecimal:true); } else { NumberToStringFormat(ref sb, ref number, format, info); } return sb.ToString(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、 Span<T>



基づいて動作するValueStringBuilderクラスのさらに興味深い例に基づいた、数値のフォーマットの例です。 コードのこのセクションの本質は、フォーマットされた数値のテキスト表現をできるだけ迅速に収集するために、コードが文字蓄積バッファにメモリ割り当てを使用しないことです。 この美しいコードは、メモリをメソッドのスタックフレームに直接割り当てます。これにより、メソッドがそのベースで機能した場合、ガベージコレクタがStringBuilderインスタンスで機能しないことが保証されます。 さらに、メソッド自体の実行時間は短縮されます。ヒープにメモリを割り当てるのに時間がかかります。 また、ベアポインタの代わりにSpan<T>



を使用すると、 stackalloc



ベースのstackalloc



作業に安心感がstackalloc



。



そして最後に、別の例をValueStringBuilder



ましょう： ValueStringBuilder



を使用するように設計されたValueStringBuilder



クラスValueStringBuilder



。 それなしでは、このクラスは存在しません。



クラスValueStringBuilder

 internal ref struct ValueStringBuilder { private char[] _arrayToReturnToPool; private Span<char> _chars; private int _pos; public ValueStringBuilder(Span<char> initialBuffer) { _arrayToReturnToPool = null; _chars = initialBuffer; _pos = 0; } public int Length { get => _pos; set { int delta = value - _pos; if (delta > 0) { Append('\0', delta); } else { _pos = value; } } } public override string ToString() { var s = new string(_chars.Slice(0, _pos)); Clear(); return s; } public void Insert(int index, char value, int count) { if (_pos > _chars.Length - count) { Grow(count); } int remaining = _pos - index; _chars.Slice(index, remaining).CopyTo(_chars.Slice(index + count)); _chars.Slice(index, count).Fill(value); _pos += count; } [MethodImpl(MethodImplOptions.AggressiveInlining)] public void Append(char c) { int pos = _pos; if (pos < _chars.Length) { _chars[pos] = c; _pos = pos + 1; } else { GrowAndAppend(c); } } [MethodImpl(MethodImplOptions.NoInlining)] private void GrowAndAppend(char c) { Grow(1); Append(c); } [MethodImpl(MethodImplOptions.NoInlining)] private void Grow(int requiredAdditionalCapacity) { Debug.Assert(requiredAdditionalCapacity > _chars.Length - _pos); char[] poolArray = ArrayPool<char>.Shared.Rent( Math.Max(_pos + requiredAdditionalCapacity, _chars.Length * 2)); _chars.CopyTo(poolArray); char[] toReturn = _arrayToReturnToPool; _chars = _arrayToReturnToPool = poolArray; if (toReturn != null) { ArrayPool<char>.Shared.Return(toReturn); } } [MethodImpl(MethodImplOptions.AggressiveInlining)] private void Clear() { char[] toReturn = _arrayToReturnToPool; // for safety, to avoid using pooled array if this instance is erroneously appended to again this = default; if (toReturn != null) { ArrayPool<char>.Shared.Return(toReturn); } } //   private void AppendSlow(string s); public bool TryCopyTo(Span<char> destination, out int charsWritten); public void Append(string s); public void Append(char c, int count); public unsafe void Append(char* value, int length); public Span<char> AppendSpan(int length); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このクラスは機能的には兄の `StringBuilder`に似ていますが、興味深い非常に重要な機能が1つあります。それは重要な型です。 すなわち 値だけで送信されます。 そして、型宣言の署名に割り当てられる型 `ref`の最新の修飾子は、この型には追加の制限があることを教えてくれます：スタックにのみ存在する権利があります。 すなわち インスタンスをクラスフィールドに出力すると、エラーが発生します。 なぜこれらすべてのスクワットですか？ この質問に答えるには、 `StringBuilder`クラスを見てください：



クラスStringBuilder

 public sealed class StringBuilder : ISerializable { // A StringBuilder is internally represented as a linked list of // blocks each of which holds a chunk of the string. It turns // out string as a whole can also be represented as just a chunk, // so that is what we do. // The characters in this block internal char[] m_ChunkChars; // Link to the block logically before this block internal StringBuilder m_ChunkPrevious; // The index in m_ChunkChars that represent the end of the block internal int m_ChunkLength; // The logical offset (sum of all characters in previous blocks) internal int m_ChunkOffset; internal int m_MaxCapacity = 0; // ... internal const int DefaultCapacity = 16;
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

StringBuilderは、内部に文字の配列へのリンクがあるクラスです。 すなわち 実際に、それを作成すると、少なくとも2つのオブジェクトが作成されます：StringBuilder自体と少なくとも16文字の文字の配列（ところで、文字列の推定長を指定することが非常に重要な理由です：その構築は、16文字の配列の単一リンクリストの生成を通過します。 -浪費）。 これは、ValueStringBuilderタイプに関する会話のコンテキストでは何を意味しますか。デフォルトでは容量はありません。 それは外部からメモリを取得し、さらにそれ自体が重要なタイプであり、ユーザーにスタック上の文字にバッファを割り当てるように強制します。 その結果、型のインスタンス全体がその内容とともにスタックに置かれ、ここでの最適化の問題は解決されます。 ヒープにメモリ割り当てがありませんか？ ヒープでのパフォーマンスの低下は問題ありません。 しかし、あなたは私に言う：なぜValueStringBuilder（またはその自己記述バージョン：それは内部であり、私たちにアクセスできない）を常に使用しないのですか？ 答えは、あなたが解決しようとしている問題を見る必要があるということです。 結果の文字列は既知のサイズになりますか？ 彼女には既知の最大長がありますか？ 答えが「はい」で、文字列のサイズが妥当な境界を超えない場合、意味のあるバージョンのStringBuilderを使用できます。 それ以外の場合、長い行が予想される場合は、通常バージョンの使用に切り替えます。



また、結論に進む前に、それを行う方法が不可能または単に危険であることに言及する価値があります。 言い換えれば、どのコードがうまく機能するかもしれませんが、ある時点で、それは最も不適切な瞬間に起動します。 繰り返しますが、例を考えてみましょう。

 void GenerateNoise(int noiseLength) { var buf = new Span(stackalloc int[noiseLength]); // generate noise }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コードは小さく、リモートです。このようにサイズを変更して、外部からスタック上のメモリを割り当てることはできません。 本当に外で与えられたサイズが必要で、コードが知っている消費者だけに知られているなら、例えばバッファ自体を取ります：

 void GenerateNoise(Span<int> noiseBuf) { // generate noise }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードは、より有益です。なぜなら、 数字を選択するとき、ユーザーに考えさせ、注意させます。 最初のオプションは、残念な状況下で、メソッドがストリームスタックでかなり浅い場合にStackOverflowException



をスローする可能性があります。パラメーターとして大きな数を渡すだけで十分です。



私が見る2番目の問題：スタックに割り当てたバッファのサイズに誤って到達できず、作業容量を失いたくない場合、もちろん、いくつかの方法があります：スタックにメモリを再度割り当てるヒープ上で選択します。 そして、ほとんどの場合、2番目のオプションの方がより好ましいでしょう（ `ValueStringBuffer`の場合はそうでした）。 「StackOverflowException」を取得するという点でより安全です。

stackallocの結論

それでは、 `stackalloc`を使用する最良の方法とその方法は何ですか？

• アンマネージコードで作業するには、特定のデータバッファーにアンマネージメソッドを入力する必要がある場合、またはメソッド本体の有効期間内に使用されるアンマネージメソッドからデータバッファーを受け入れる必要がある場合。
• 配列を必要とするメソッドの場合。ただし、メソッド自体の期間中も同様です。 書式設定の例は非常に優れています。このメソッドを頻繁に呼び出して、ヒープに一時配列を割り当てることができます。
• 安全でないバージョンのインタラクションを使用している場合、リンク先のメソッド（void *）の動作を慎重に確認する必要があります。 それらがどこかにそれを与えると、スタックが破損する可能性がさらにあります。たとえば、キャッシュのために外部メソッドがリンクを渡すことを決定しないことを保証することはできません。 これが除外されていることが確実な場合、使用は安全です。
• ref struct
  
  
  
  体型またはSpan型を使用する機会がある場合、stackallocを使用すると、コードの管理領域に入ります。つまり、コンパイラは、意図したとおりに型を使用できないようにします。

このアロケーターを使用すると、アプリケーションのパフォーマンスを大幅に改善できます。

本全体へのリンク

• CLR Book： GitHub
• リリース0.5.0の書籍、PDF： GitHubリリース