.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/

多くのプロジェクトでは、GCは全く問題にならないし、考えることもないよ。でも、あるプロジェクトでは大きな問題で、常にそのゴーストのことを考えなきゃいけない。ゴーストに悩まされないように工夫する必要があるんだ。もしいつもそんな風に考えなきゃいけないなら、非GC言語を使った方がいいかもね。

C/C++でパフォーマンスが重要なものを書くのが、全体的に見て少ない労力で済むんじゃないかって、最近よく考えるんだよね。パフォーマンス重視のゼロアロケーションのC#とC/C++は、裏技みたいなもので、言語としてのサポートが全然違う。ボクシンググローブと外科用手袋みたいな感じ。C#でもできるけど、いろんな抽象化があってさ。特別なパフォーマンスAPI、C#、IL、アセンブリ。結果は言語のバージョンやランタイムのバージョン、プラットフォーム、IL2CPP/Burst/Mono/dotnetによって変わるけど、C/C++はコンパイラという一つの抽象化レイヤーだけで、コンパイルしたらそれが固定される。できるだけ正確に、一貫して、シンプルな方法でやりたいんだよね！ .cppと.csを一緒にコンパイルするビルド環境があれば、すごく助かるな。 ---- 抽象化についての例として、こんなのがある。 void addBatch(int *a, int *b, int count) { for(int i=0; i < count; i++) { a[i] += b[i]; } } 対して、 [MethodImpl(MethodImplOptions.AggressiveOptimization)] public static void AddBatch(int[] a, int[] b, int count) { ref int ra = ref MemoryMarshal.GetArrayDataReference(a); ref int rb = ref MemoryMarshal.GetArrayDataReference(b); for (nint i = 0, n = (nint)count; i < n; i++) { ra[i] += rb[i]; } } （これは明らかに作り話の例だけど、抽象化の種類を示したかったんだ。）

「モデレートは安全でない」。実際、ほとんどの場合その逆なんだよね。void*はGCを含まないことが多いから、むしろ安全だよ。https://learn.microsoft.com/en-us/dotnet/standard/unsafe-cod...を読むことをおすすめするよ。

それは記事で説明されている内容と完全に1対1の対応ではないと思う。C#のスパンも君のスパン型も型と境界が安全だけど、前者はrefキーワードのおかげで使用に追加の制約があって、ランタイムを介さずにライフタイムエラーがないことが保証されているんだ。

逆に、直接サポートのない言語にGCを導入すると、基本的にいつも劣ったGCを実行していることになるよ。なぜなら、リード/ライトバリアによって可能になった多くの進歩が、言語のサポートなしでは本当に利用できないから。そうすると、人々は「GCは悪い」って叫ぶけど、実際には最悪のものを使わざるを得なかった言語で使ったからなんだよね。

ありがとう！記事を書いてる間にコードサンプルを何度も見直したから、swap()はただの名残だったんだ。そう、正解！タプルのスワップに置き換えられる予定だったんだよね：「(a,b)=(b,a)」。今、完了したよ。 :)

Spanって、まさに同じ概念じゃない？

いや、GoのスライスはArraySegmentに似てるけど、サイズ変更や追加時のコピーがあるんだ。 .NETがサポートしているような、任意のメモリ（GC所有のものも含めて）を統一的に参照できるbyrefメカニズムはないよ。

C#の文字列は不変なんだ。文字列を扱うにはStringBuilderを使うべきだよ。