Ruby 2.0 Garbage Collection
There’s been a lot of talk about the improvements in Ruby 2.0’s Garbage Collection performance. That’s a great thing, because GC in older versions of Ruby wasn’t very performant. Most of the conversation about generational GC (or other strategies) revolves around making Ruby GC more efficient. This has a great impact on your users, because less GC time means that their pages return faster. But wha
Hey Judy, don't make it bad
EngineeringHey Judy, don’t make it badLast week we explained how we greatly reduced the rendering time of our web views by switching our escaping routines from Ruby to C. This speed-up was two-fold: the C… Last week we explained how we greatly reduced the rendering time of our web views by switching our escaping routines from Ruby to C. This speed-up was two-fold: the C code for escaping HTML was
Dynamic Method Definitions | Tenderlove Making
TL;DR: depending on your app, using define_method is faster on boot, consumes less memory, and probably doesn’t significantly impact performance. Throughout the Rails code base, I typically see dynamic methods defined using class_eval. What I mean by “dynamic methods” is methods with names or bodies that are calculated at runtime, then defined. For example, something like this: class Foo class_eva
The Cost of Ruby 1.9.3's GC::Profiler | James Golick
This is a long one, and y'all are busy I'm sure so here's the tl;dr: If you run ruby in production, you need to keep track of GC stats. Ruby 1.9.3's GC::Profiler does a bunch of really weird shit. It keeps a 104 byte sample of every GC run since it was enabled forever. Calling GC::Profiler.total_time loops over every sample in memory to calculate the total. The space used to keep those samples in
徹底解剖「G1GC」実装編（β版）
本書はOpenJDK7のG1GCの実装と、それに関連する技術を解説します。 目次 スポンサーのみなさま はじめに 1.準備 2.オブジェクト管理機能 3.アロケータ 4.ヒープ構造 5.オブジェクト構造 6.HotspotVMのスレッド管理 7.スレッドの排他制御 8.GCスレッド（並列編） 9.GCスレッド（並行編） 10.並行マーキング 11.退避 12.予測とスケジューリング 13.正確なGCへの道 14.ライトバリアのコスト さらに勉強したい人へ その他参考文献 以下から（ある時点で）最新のebookをダウンロードできます。 徹底解剖「G1GC」実装編-20120915.epub 徹底解剖「G1GC」実装編-20120914.mobi 徹底解剖「G1GC」実装編-20120914.pdf 謝辞 本書はスポンサーのみなさまの金銭的支援によって執筆されました。 スポンサーのみなさま あ
Python の GC のデバッグ機能 - methaneのブログ
Python のデーモン型のプログラム（具体的に言うと Loggerhead という bzr のリポジトリブラウザ）が大量（具体的に言うと100MB以上）メモリを食っていたので、それを調べた時のメモ。 まず、本当にそれだけのメモリを利用しているのかどうかを meliae というメモリプロファイラで調べたんだけど、18MBくらいしか使ってなかった。 meliae の使い方はまた今度に回すとして、今回はそんなにメモリを使うはずがないのにメモリを使ってしまっているケースについて。 この場合は、循環参照を大量に作ることによってメモリブロックがたくさん確保され、循環参照コレクタが実行された後も（メモリブロック内に1つでも生き残っているオブジェクトがいるなどの理由で）OSにメモリブロックが返されないという原因が考えられる。（循環参照以外の原因でメモリが大量に確保されてる可能性もあるんだけどね） 今日の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
