Amazon.co.jp: Rubyソースコード完全解説: Ruby Hacking Guide: 青木峰郎: 本
ガベージコレクション
Ruby には使われなくなったメモリを自動的に検出し解放してくれる ガベージコレクションの機能がある。 この節ではこのガベージコレクションの詳細を追ってゆく。 オブジェクトの管理 Ruby の GC は Ruby のオブジェクトのみが対象だ。かつ、Ruby が 生成し管理しているメモリにないといけない。逆に言うとユーザが勝手に 割りあてたメモリまでは面倒をみてくれないということだ。たとえば 以下の関数はメモリリークを起こす。 void koreha_dame() { malloc(1024); /* メモリをもらっては捨てる */ } 一方で以下の関数はメモリリークを起こさない。 void daijoubu() { rb_ary_new(); /* Ruby の配列を作っては捨てる */ } Ruby のオブジェクトはようするに struct RVALUE だったから、オブ ジェクトの管理
Rubyで実装し直したFixnum#timesの方が速い
http://d.hatena.ne.jp/Gimite/20080802/1217647596 でちょっと思い出した、前からやってみたかった実験をやってみたらだいたい思った通りな感じだった。 class Fixnum def times i = 0 s = self while i < s yield i i += 1 end end end s = 0 1000000.times{|i| s+=i } p s みたいなコードを書くわけです。ご存知の通り、 Ruby の Fixnum#times は C 言語で実装されてます。それを Ruby で実装しなおしたら当然遅くなります。ホント時間のムダです。実はそうでもないんです。 > time ruby1.9 bench.rb 499999500000 ruby1.9 bench.rb 0.10s user 0.00s system 91%
ポストMongrel時代のWebサーバ - Hello, world! - s21g
と言いつつ、自分ではMongrel使ってない（主にlighttpd）のですが、 RailsChatでshachiさん、くまくまーのmaihaさん、笹田さん、のりおさんと話してた時に出てきた、最近のWebサーバのメモ。 thin 軽量で高速らしい。 Ebb libevとかを使っていてthinより速いらしい。 小さいファイルが弱点だったが、最近克服されたらしい。 swiftply Webサーバではない。プロクシフレームワーク。 (See also Swiftiplyのアーキテクチャとベンチマーク) あとで試す。 話は変わりますが、上述のプログラムの大半の実装はCで書かれていて、 インターフェイスの部分だけRubyで実装されている感じのものが 多いですね。これこそがRubyの真骨頂だと思う。 いろんな言語を使ってきたけれど、 最近はCとRubyの組み合わせが良い感じです。 C言語用の高性能プリプ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
