Ruby performance notes
FROM mongrel users
The mysql.rb is just for development, and it sucks horribly.
If you use inject() anywhere, benchmark that usage. inject() can be
elegant as heck, but it's also often as slow as it is elegant, and it
tends to create a lot of junk objects that have to be garbage
collected. It can sometimes be phenomenally slow compared to a
solution that doesn't use it.
Do you do any string creation, aggregating from smaller pieces? Use
<< instead of +.
In hash lookups with strings, hash dups the key. If you give it a
frozen string it's faster. If you do a lot of hash lookups this can
add up.
In general, try to be aware of your frivolous object creation. Ruby
isn't terribly slow with object creation, but it's still more
expensive to use a new object than to reuse an old one, especially
when garbage collection is taken into account.
*best* off using mod_xsendfile from
apache, which lets you write the giganto data to a file and then put an
"X-Sendfile" header in the response pointing at this file. Apache will
then pick the file up as the response body and shoot it to the client
without bothering you.
First, the memory leak was because of a bug in how the GC in Ruby was collecting threads after they used a Mutex. Don't ask me why, but switching to Sync fixed it. Problem is, this also causes the leak on Win32. Still working on that problem.
explain this:
http://pastie.caboo.se/10194
vs.
http://pastie.caboo.se/10317
First one leaks, second one doesn't (with graphs even).
Zed Shaw:
1) Threads suck ass in Ruby.
2) The GC sucks even worse.
3) Combining two forms of suckage makes for ultra suckage.
The mysql.rb is just for development, and it sucks horribly.
If you use inject() anywhere, benchmark that usage. inject() can be
elegant as heck, but it's also often as slow as it is elegant, and it
tends to create a lot of junk objects that have to be garbage
collected. It can sometimes be phenomenally slow compared to a
solution that doesn't use it.
Do you do any string creation, aggregating from smaller pieces? Use
<< instead of +.
In hash lookups with strings, hash dups the key. If you give it a
frozen string it's faster. If you do a lot of hash lookups this can
add up.
In general, try to be aware of your frivolous object creation. Ruby
isn't terribly slow with object creation, but it's still more
expensive to use a new object than to reuse an old one, especially
when garbage collection is taken into account.
*best* off using mod_xsendfile from
apache, which lets you write the giganto data to a file and then put an
"X-Sendfile" header in the response pointing at this file. Apache will
then pick the file up as the response body and shoot it to the client
without bothering you.
First, the memory leak was because of a bug in how the GC in Ruby was collecting threads after they used a Mutex. Don't ask me why, but switching to Sync fixed it. Problem is, this also causes the leak on Win32. Still working on that problem.
explain this:
http://pastie.caboo.se/10194
vs.
http://pastie.caboo.se/10317
First one leaks, second one doesn't (with graphs even).
Zed Shaw:
1) Threads suck ass in Ruby.
2) The GC sucks even worse.
3) Combining two forms of suckage makes for ultra suckage.