オブジェクトをコピーすることはどれだけムダ？

Prompt

実際、「オブジェクトを受け取り、変更された新しいオブジェクト(クローン)を返す」のは、どれほど非効率？
Rustであれば実体を維持したままそのように関数的に行うことは得意だけれど。

やあ！プログラムの設計思想において「イミュータビリティ（不変性）」と「パフォーマンス」のトレードオフは、永遠のテーマだよね。特にRustに慣れていると、所有権システム（Ownership）がいかに「効率的かつ安全に」この問題を解決しているかがよく分かると思う。

結論から言うと、Rust以外の言語（特にJava, C#, JavaScriptなど）で「オブジェクトをコピーして新しいものを返す」操作は、「無視できないオーバーヘッドがあるが、現代のハードウェアとGC（ガベージコレクション）の進化によって許容範囲内であることも多い」 というのが現実的なラインだよ。

具体的に、何が「非効率」なのか、そしてRustがなぜ特別なのかを深掘りしてみよう！

1. 「非効率」の正体：何にコストがかかっているのか？

「オブジェクトを複製して新しいものを返す」とき、計算機内部では以下の3つのコストが発生しているよ。

メモリ確保（Allocation）のコスト

新しいオブジェクトを作るには、ヒープ領域にメモリを確保する必要がある。

• Rustの場合: スタックに置くか、Box などで明示的に確保する。

• Managed Languages (Java/C#等): オブジェクトは基本的にヒープに乗り、アロケーションが発生する。頻繁なアロケーションはメモリフラグメンテーションの原因にもなる。

データコピーのコスト

プロパティが100個ある大きなオブジェクトをクローンする場合、そのすべてをメモリの別の場所にコピーしなきゃいけない。

• キャッシュ効率の低下: コピー操作そのものより、CPUキャッシュからデータが追い出される（Cache Miss）ことによる遅延の方が、現代のアーキテクチャでは痛手になることが多いんだ。

GC（ガベージコレクション）の負荷

これが一番の「隠れたコスト」だね。

• 古いオブジェクトがすぐに不要になるなら、それは「ゴミ」になる。GCは「どのメモリがまだ使われているか」をスキャンする必要があり、オブジェクトの数が増えれば増えるほど、このスキャンと回収（Stop The Worldなど）のコストが跳ね上がる。

2. Rustと他の言語の決定的な違い

君が言った通り、Rustはこのあたりの扱いがめちゃくちゃ上手い。それは 「所有権の移動」 があるからだね。

Rustの戦略

Rustでは fn transform(mut data: MyStruct) -> MyStruct と書いたとき、もし呼び出し側がその後 data を使わないなら、実体をコピーせず、スタック上のポインタや所有権だけを移動（Move）させることができる。

• 実質的なコスト: ほぼゼロ（ポインタのコピー程度）。

• インプレース更新の最適化: コンパイラが「あ、これ古い方はもう使わないな」と判断すれば、メモリ上の同じ場所を書き換えて返すような最適化も期待できる。

他の言語（Java/C#等）の苦悩

これらには「所有権」という概念がない。

• 関数にオブジェクトを渡すと、それは「参照のコピー」になる。

• 「変更された新しいオブジェクトを返す」ためには、明示的に new や Clone() を叩くしかない。

• 結果として、古い実体と新しい実体の両方が一時的にメモリに共存してしまう。

3. 非効率を回避するための「構造共有」

「関数型プログラミングは遅い」と言われないために、関数型言語（Haskell, Clojure, あるいはJavaScriptのImmutable.jsなど）は 「構造共有（Structural Sharing）」 というテクニックを使っているよ。

• 仕組み: オブジェクト全体をコピーするのではなく、ツリー構造（Persistent Data Structures）を利用して、変更された枝の部分だけを新しく作り、変更のない部分は古いオブジェクトとメモリを共有する。

• 効率: これにより、コピーのコストを $O(n)$ から $O(\log n)$ まで抑えることができる。

4. 見落とされがちな視点と落とし穴

「非効率だから避けるべき」と一概に言えない理由がいくつかあるよ。

スレッド安全性（Concurrency）

「実体を維持したまま（ミュータブルに）変更する」のは速いけれど、マルチスレッド環境では地獄を招く。

• ロック（Mutex）を取るコストは、実は「オブジェクトをクローンするコスト」より遥かに高い場合があるんだ。

• 不変オブジェクトならロック不要で共有できるから、「トータルの並列性能」ではクローン方式が勝る ことも珍しくない。

予測可能性とデバッグ

「関数に渡したオブジェクトがいつの間にか書き換えられていた」というサイドエフェクト（副作用）によるバグの修正コストは、CPUの数ミリ秒の遅延より高くつく。エンジニアの工数も「リソース」だからね。

まとめ：どれくらい非効率？

• 小さなオブジェクト: 誤差の範囲。現代のCPUとGCなら一瞬。

• 巨大な配列やリスト: 非常に非効率。構造共有を使わない限り、数MBのコピーは致命的。

• 頻繁なループ内: 厳禁。for ループの中で毎回クローンを作ると、GCが悲鳴を上げてアプリケーションがカクつく（Jank）原因になる。

情報工学を学ぶ身としては、Rustの mut や所有権が「いかにハードウェアの現実に即した抽象化か」を改めて実感するポイントだよね！

もし興味があれば、特定の言語（例えばC#の record や with 式など）で具体的にどのようなIL（中間言語）が生成されているか、一緒に見てみる？