こんにちは。Aiming エンジニアの久保田です。 僕の携わっているプロジェクトでは、近頃、Unity製クライアントのパフォーマンスの調査や改善を行っている最中です。 プロファイラを眺めていると、僕達が書くアプリケーションレイヤのコードが目立って遅い、ということは珍しいのですが、代わりにC#世界のスパイクとしてよく顔を出すのが、GC実行時間です。 C#は、タイプセーフでありながら人間にやさしく、getter/setter、async/await、Rx、ロケットなラムダ式、他他他…最新型の言語への影響も多大な、ファッション的にも◎な言語です。しかし、闇雲に全ての機能をタダで……というわけにはいかず、ことパフォーマンス面においては、GCというなかなか高い代償を支払うことになりかねないわけですね。 結論としては、UnityのGCは、皆が期待していたほど高性能ではなく、現状では僕達が書くC#が発生
プログラムが使用しなくなったメモリ上の空間を解放し、他のプログラムが使えるようにするのは、古くはプログラマの役割でした。それがゆえに、しばしば解放を忘れるというヒューマンエラーを引き起こし、ついには「メモリ不足です」と宣告され、あるいはオペレーションシステムもろとも轟沈し、作業中のデータはすべて消え失せ、モニタの前のユーザーは声にならない叫び声をあげるというシーンがしばしば見られました。 そこで研究され実装されたのが、ガベージコレクションです。これはメモリの解放を人任せにせず、プログラム自身が行えるようにするもので、プログラマの苦役の幾ばくかをも解放してくれました。 とはいえ、その実装方法やアルゴリズムは多種多様で、ガベージコレクションがあるから大丈夫、という思い込みだけでプログラムを作成していると、思わぬ落とし穴に転げ落ちることになります。 本書はアルゴリズムはもちろん、その実装方法とメ
ささだこういちさんによるRGenGCの発表資料を読みました。 英語だったので条件反射的にｳｯとなったのですが印刷してボールペンを片手に辞書を開きながら読み通しました。 RGenGCとは何物か、その仕組みはどうなっているのかということに注目してまとめます。誤りがあれば指摘していただけると助かります。 世代別GCの復習 世代別GCではオブジェクトを新世代と旧世代にわけます。 オブジェクトは最初新世代として生成され、一度でもGCして生き残ったオブジェクトは旧世代となります。ふだんのGC (minor GC)では新世代のみを扱い、旧世代オブジェクトは死んでいても回収しません。たまに行うmajor GCで旧世代も含めてGCします。 世代別GCのminor GCでは次のことをします: ルートオブジェクトからたどれるオブジェクトにマークをつけます マークをつけたオブジェクトは旧世代へ移行します ただしマ
有給を駆使し一足早くクリスマス休暇に突入、ヒャッホイ Ingress やるぜーと 意気込んでいた矢先ノロウイルスにやられダウンした。かなしい。鎮まれ俺の胃袋・・・ そんな腹痛日和の気晴らしとして今日は Garbage Collection Advent Calendar に参加してみることにしました。 Advent Calendar 初体験につきよくわかってないけど勝手に参加していいんですよね？ GC というとジェネレーショナルだのパラレルコンカレントだのといった話が目立ちがちだけれど、 現実の問題というかブラウザを相手にするとそれ以外の細々とした面倒が目につく。 GC つき言語 (JavaScript) のコードと C++ で書かれたコードとの連携は最たる面倒の１つ。 たとえば WebKit の DOM は C++ で実装されており、 C++ のオブジェクトは JavaScript 処理
2010年03月20日04:30 カテゴリ書評/画評/品評Lightweight Languages Every Byte is Sacred - 書評 - ガベージコレクションのアルゴリズムと実装 著者より献本御礼。 ガベージコレクションの アルゴリズムと実装 中村成洋 / 相川光 / 竹内郁雄監 これほど地味かつ即実務に役立たない、しかし確実にプログラマーの滋養になる本が出版される日本の出版界に乾杯!世界で二番目(著者調べ)、国内で初のGC本は、実に滋味豊かだ。 とはいえ、本書はこの話題に関してMECEというわけでもない。というわけで本entryでは本書に何が書いていないかを主に紹介していく。何が書いてあるかは本書で確認すればよいのだから。 本書「ガベージコレクションのアルゴリズムと実装」は、コンピューターの資源管理の技術の一つ、ガベージコレクション(以下GC)についてまるまる一冊を費
最近クックパッドでは、アプリケーションサーバの大半が Rails 2.3 から Rails 3 に置き換わったのですが*1、リリース前のベンチマークの時点ではあまりパフォーマンスが出ず四苦八苦していました。具体的には Rails 2.3 の時と比べ MRI 1.8.7 だとレスポンスタムが200%ぐらい遅い結果でした。Rails 3 になって実装が Merb core を取り入れ疎結合で綺麗になった反面、より多くのオブジェクトと・メモリを利用する様になった影響かと思います。 そこで Ruby インタプリタの変更*2を行い検証をしたところ MRI 1.8.7 (Rails 2.3と比べ) 約200%遅い MRI 1.8.7 -> Ruby Enterprise Edition 1.8.7 2011.03 (tcmalloc 無効) 約180%低速 MRI 1.8.7 -> Ruby Ente
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: ガベージコレクションのアルゴリズムと実装: 中村成洋 (著), 相川光 (著), 竹内郁雄 (読み手), 竹内郁雄 (監修): 本