RubyとPythonにおけるガベージコレクションの視覚化 | POSTD
本稿は、ブダペストで開かれたイベント「 RuPy 」で、Pat Shaughnessyが披露したプレゼンの内容をまとめたものです。 プレゼンの映像はここ から視聴できます。 本稿は当初、 同氏の個人ブログ に投稿されましたが、同氏の了承を得て、Codeshipに再掲載します。 このイベントは「RubyとPython」に関するカンファレンスなので、RubyとPythonでは、ガベージコレクション（以下「GC」）の動作がどう違うのかを比較すると面白いだろうと私は思いました。 ただしその本題に入る前に、そもそもなぜ、GCを取り上げるのかについてお話しします。正直言って、すごく魅力的な、わくわくするテーマではないですよね？ 皆さんの中でGCと聞いて、心がときめいた方はいらっしゃいますか？ ［実はこのカンファレンス出席者の中で、ここで手を挙げた人は数名いました！］ Rubyコミュニティで最近、Rub
Python の GC のデバッグ機能 - methaneのブログ
Python のデーモン型のプログラム（具体的に言うと Loggerhead という bzr のリポジトリブラウザ）が大量（具体的に言うと100MB以上）メモリを食っていたので、それを調べた時のメモ。 まず、本当にそれだけのメモリを利用しているのかどうかを meliae というメモリプロファイラで調べたんだけど、18MBくらいしか使ってなかった。 meliae の使い方はまた今度に回すとして、今回はそんなにメモリを使うはずがないのにメモリを使ってしまっているケースについて。 この場合は、循環参照を大量に作ることによってメモリブロックがたくさん確保され、循環参照コレクタが実行された後も（メモリブロック内に1つでも生き残っているオブジェクトがいるなどの理由で）OSにメモリブロックが返されないという原因が考えられる。（循環参照以外の原因でメモリが大量に確保されてる可能性もあるんだけどね） 今日の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
