C#における安全なゼロコピー操作

.NET CMSでスパンや「public readonly record struct」を使って真剣なパフォーマンス向上を見つけた人いる？ この返答は「.NET CMS」の部分には直接答えてないよ。最適化について考えるべきタイミングを伝えたかっただけ。こういうマイクロ最適化は、特定のパフォーマンス問題を解決しようとしているときに考えるのがベストだよ。特に、あまりアクセスがないサイトを扱っているときはね。俺は、各ページの読み込みに5秒かかる小規模ビジネスのeコマースサイトを使ったことがあって、何かを買うのを諦めたことがある。その場合、サイトをプロファイリングして問題を特定するのは非常に価値がある。アクセスが多いサイトでは、こういうパフォーマンス最適化がコストを節約するのに役立つことがある。もしサービスを運営するのに100台のサーバーが必要で、パフォーマンスを調整して75台に減らせるなら、それはエンジニアリングの努力に見合うかもしれない。俺のおすすめは、何らかのプロファイラーを使うこと。アプリケーション全体でホットスポットを特定して、特定のパフォーマンス問題の原因を探るのがいい。ホットスポットを特定したら、BenchmarkDotNetで問題のマイクロベンチマークを作成して、スパンのようなツールを使って問題を解決してみて。

CMSや似たような状況では、スパンよりも高レベルの変更から大きなパフォーマンス向上が得られるよ。HTTPキャッシュコントロールヘッダーを正しく使ってCDNと組み合わせることで、桁違いの改善が得られる。より効率的なレイアウトテンプレートを使ってHTML/CSS/JSを減らすだけでも、サイト全体に乗数効果をもたらすことができる。俺の経験では、最大の成果はブラウザのF12ツールのネットワークタブを使うことで得られた。次に大きかったのは、プロダクションで動作しているAzure Application Insightsプロファイラー。最もコストのかかるデータベースクエリのトップ10を見て、それを徹底的に調整するのが重要。スパンのようなものは、共有ライブラリの作者にとっては重要だけど、「エンドユーザー」がウェブアプリを書く場合にはそれほどでもない。そういえば、NuGetパッケージのバージョンや.NETフレームワークのバージョンを9や10に更新するだけで、その使用を増やせるよ。これで、ほんの少しの努力で何千ものマイクロ最適化が得られる！

CMSの場合、主要なボトルネックはDBクエリにあることが多いと思うよ。特にC#みたいにデフォルトで結構速い言語の場合はね。こういう低レベルの最適化に行く前に、ちゃんと測定する必要があるよ。多分、この場合はフレームワークやCMSにオーバーヘッドがあって、どう使うかを理解することで一番改善できると思う。スパンは、低レベルのライブラリコードを書くときに注意すべき最適化だね。

普通、CMSのパフォーマンス問題はデータベースやレンダリングコンポーネントの使い方、キャッシュの仕方に関連してることが多いよ。私が経験した2つの.NET CMS、SitecoreとOptimizelyでは、スパンみたいなものはほとんど改善には繋がらないと思う。むしろ、ORMの使い方を見直したり、直接SQLを使ったり、レンダリングを別の方法でキャッシュしたり、CMSのAPIが正しく使われているかを確認する方が重要だよ。

他の人も言ってるけど、CMSのようなプロジェクトではボトルネックはデータベースやキャッシュにあることが多いよ。スパンやスタックアロック、値構造体は、画像処理やゲーム、"AI"/ベクトルクエリ、データベースエンジンの実装みたいな重いデータや数値を扱うシナリオを書くときに重要になるね（昨日のC++を使うって発表した人たちの話も見てみて、RustやGo、Erlang、Java、C#との比較がされてたよ）。私はCMSのワークロードを思い出させるアプリケーションを書くことが多いけど、構造体を使うこともあるけど、過去6年間で低レベルの最適化スキルを本格的に使ったのは数回だけで、95%の時間はDBの使い方が悪いことが原因だね。

誰か、.NETのCMSでSpanや「public readonly record struct」を使って、真剣なパフォーマンス向上を見つけた人いる？ページは通常、ファイアアンドフォゲットだから。Spanの利点は、.NETのアップグレードに合わせて得られるものが多いよ。Spanは低レベルの最適化で、ASP.NETの内部にはユーザーコードよりもずっと効果がある。Spanが追加されて以来、各バージョンの.NETはその使い方を改善してきたし。さらにC#では、コンパイラは意味があるときにSpanのオーバーロードを優先するから、最新の.NETに再ビルドするだけでその利点を享受できる。これが「真剣な」利点かどうかは好みの問題でもあるし、あなたのコードが常に低レベルのことをしているわけではないってことを思い出させてくれる。例えば、データベースのクエリ時間は一般的にもっと大きな影響を与えるしね。 「public readonly record struct」については、注意が必要だよ。デフォルトでその冗長なバージョンを使い始めるコードベースをいくつか見たけど、期待以上にひどいパフォーマンスの落ち込みを招いてしまった。なぜ「record」がデフォルトでクラスになっているのか、構造体の動作を選択する必要があるのかには、たくさんの理由がある。クラスの方が理解しやすいし、パフォーマンスのトレードオフも把握しやすい。GCは友達であって敵じゃない、特に短命のデータに対してはね。（Gen0のコレクションはしばしば非常に速い。ナースリーはファイアアンドフォゲットのデータの回転のために設計されている。世代型ガベージコレクターの仕事は、回転と安定を分け、回転を素早く処理して安定を保つことだから。）構造体は値渡しだから、同じスタックに留まる「ラッキーパス」を出ると、どんどんコピーされちゃう。モデルに他の構造体がたくさん含まれていると、メモリをもっと頻繁にコピーすることになる。構造体が特定のスタックフレームの制限を超えると、結局GCヒープにボックス化されて、ヒープのアロケーションを節約できない。クラスは参照渡し。構造体を使って不変データモデルを作るために「readonly」を使っているなら、すべてのコピーが不変データの変更から積み重なって新しい構造体を作ることになる。一方で、「通常の」不変レコード（クラス）は、互いに参照を共有できるから、変更しない部分は同じ参照を使って同じメモリを共有できる。モデルが整数が数個以上で、何らかのネストや複雑な関係を持っているなら、「public readonly record struct」は早すぎる最適化で、実際にはパフォーマンスを損なうことになる。すべてのデータをスタックに移せるわけじゃないし、移すべきでもない。トレードオフがあることを忘れないで、健全なパフォーマンスの.NETアプリケーションは、スタックとGCの賢い組み合わせを使うことが一般的だから、どちらも重要なツールなんだ。言った通り、「public record」がデフォルトで「クラス」になっている理由や、「public readonly record struct」が冗長なオプトインである理由を覚えておくのは役に立つよ。

これは好みの問題だね。C#はより一般的なパターンを許可するけど、Rustはもっと多くのことを許可する。例えば、RustではSpan（Rustではスライスと呼ばれる）をどこにでも保存することができる（ヒープ上でも、ただしこれは稀）。

主な違いはこれだと思う。C#はGCがあって、システムは使用中のメモリを保護するけど、スパンやメモリなどを許可する一方で、ライフタイムに関する考慮が雑なためにいくつかの制約がある。でも一般的には「簡単」に使えるから、ライフタイムを気にしなくていい。Rustはライフタイムのセマンティクスが言語のコアに組み込まれていて、コンパイラは安全なものについてずっとよく知っているけど、証明できないけど安全なものからは早めに禁止される（でも経験に基づいてチェックを改善している）。その知識のおかげで、アロケーションをより正確に扱えるようになるんだ。個人的にはアセンブリやC、C++などのバックグラウンドがあるから、Rustの魅力は理解できるし、パフォーマンスが必要な経験の浅い開発者がクリティカルなコンポーネントにRustを選ぶのはプラスだと思う。自分もRustでプロジェクトをやってみようと思ってるけど、今のところRustのわずかなパフォーマンス向上が、C#が許す「ちょっと雑な」接続ができることから得られる「生産性」の向上を上回るプロジェクトは見たことがないな。

これが役に立つかも: 「Rustの借用チェッカーとC#の比較」 https://em-tg.github.io/csborrow/