この非常によく似た質問に出くわしましたが、その質問にはQuickFIXのタグが付けられており（これは私の質問には関係ありません）、ほとんどの回答はQuickFIX関連です.
私の質問はもっと広いです。C# を使用してFIX プロトコルメッセージを解析する最も効率的な方法を探しています。<SOH>背景として、FIX メッセージは、ASCII文字 (0x01)で区切られた一連のタグ/値のペアで構成されます。メッセージ内のフィールド数は可変です。
メッセージの例は次のようになります。
8=FIX.4.2<SOH>9=175<SOH>35=D<SOH>49=BUY1<SOH>56=SELL1<SOH>34=2482<SOH>50=frg<SOH>
52=20100702-11:12:42<SOH>11=BS01000354924000<SOH>21=3<SOH>100=J<SOH>55=ILA SJ<SOH>
48=YY77<SOH>22=5<SOH>167=CS<SOH>207=J<SOH>54=1<SOH>60=20100702-11:12:42<SOH>
38=500<SOH>40=1<SOH>15=ZAR<SOH>59=0<SOH>10=230<SOH>
各フィールドでは、タグ (整数) と値 (ここでは文字列) が「=」文字で区切られています。(各タグの正確なセマンティクスはプロトコルで定義されていますが、それはこの質問とは特に関係ありません。)
基本的な構文解析を行う場合、FIX ヘッダーからの特定のタグのほんの一握りだけに関心があり、可能なすべてのフィールドへのランダム アクセスを実際に行うわけではない場合がよくあります。私が検討した戦略は次のとおりです。
を使用し
String.Split、すべての要素を繰り返し処理し、ハッシュテーブルにタグをインデックス マッピングに配置する - 必要に応じて、すべてのフィールドへの完全なランダム アクセスを提供します。(わずかな最適化) を使用して
String.Split、関心のあるタグの配列をスキャンし、タグからインデックスへのマッピングを別のコンテナーに配置します (かなり少数のアイテムである可能性があり、アイテムの数は解析前にわかっているため、必ずしもハッシュテーブルである必要はありません)。String.IndexOf該当するフィールドのオフセットと長さを使用してフィールドごとにメッセージ フィールドをスキャンし、適切な構造体に格納する
最初の 2 つについて - 私の測定値String.Splitはかなり高速であることを示していますが、ドキュメントによると、メソッドは結果の配列の各要素に新しい文字列を割り当てます。これは、多くのメッセージを解析している場合、大量のガベージを生成する可能性があります。.NET でこの問題に取り組むためのより良い方法を見つけられる人はいますか?
編集：
私が省略した 3 つの重要な情報:
タグは、FIX メッセージ内で必ずしも一意であるとは限りません。つまり、特定の状況下では、タグの重複が発生する可能性があります。
特定のタイプの FIX フィールド
<SOH>では、データに「embedded」を含めることができます。これらのタグは「データ」タイプと呼ばれます。辞書には、このタイプのタグ番号がリストされています。最終的な要件は、メッセージを編集できることです (特に値を置き換えます)。