[過去ﾛｸﾞ]
Rust part30 (1002ﾚｽ)
Rust part30 http://mevius.5ch.net/test/read.cgi/tech/1748392296/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
417: デフォルトの名無しさん [sage] 2025/06/02(月) 20:56:39.33 ID:OnNK0eHp 小さいメモリを確保したり解放したりを頻繁にやるわけではないユースケースでは GC はそんなに速度に影響しない。 するとしても回避策はある。 そんなことより Go の問題点はメモリ管理を自動化しておきながらメモリアクセス違反をあまり防げないことだな。 C/C++ から移行する分にはそんなもんだろと思えるが、メモリ安全性を期待したら失望すると思う。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/417
423: デフォルトの名無しさん [sage] 2025/06/02(月) 21:40:20.45 ID:OnNK0eHp >>421 確保しようとするメモリが大きくても小さくても一回あたりの確保・解放に必要な実行コストはあまり差がない。 大きさではなく回数が効いてくるので頻繁な確保・解放がないなら GC のコストは小さいよ。 画像処理関係は大きなデータは扱うがメモリを確保・解放する回数が大きいわけではない。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/423
426: デフォルトの名無しさん [sage] 2025/06/02(月) 21:56:07.57 ID:OnNK0eHp Go の GC もヒープメモリの確保と解放のコスト自体は C と同程度じゃないかな。 生存しているか (参照が残っているか) どうかの判定にコストがかかっているので依存関係の複雑なデータ構造だと速度的には不利になる。 どうせそのあたりを意識しながら設計するなら Go より Rust のほうがいいかなぁとは思う。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/426
427: デフォルトの名無しさん [sage] 2025/06/02(月) 22:01:25.40 ID:OnNK0eHp 逆にもう手に負えないほど複雑なデータ構造になってしまったときは GC の実行コストを受け入れてでも任せてしまいたいということはあるかもね。 http://mevius.5ch.net/test/read.cgi/tech/1748392296/427
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.046s