Ruby 1.9.1 e JRuby atualmente lideram as implementações do Ruby, quando se trata de desempenho. Entretanto, por diversas razões, migrar para qualquer uma destas implementações Ruby, pode não ser possível ainda, como o Ruby 1.9.x quebra a compatibilidade com 1.8.7 em algumas áreas e o JRuby ainda carece de algumas bibliotecas Ruby que usam extensões nativas. Com isso em mente, MRI 1.8.x parece que chegou para ficar para o futuro próximo, por isso existe interesse em melhorar o seu desempenho.
Brent Roman traz agora algumas melhorias de desempenho para Ruby 1.8.x IRM. Ele começou tentando corrigir vazamentos de memória no Ruby, especialmente em continuations:
A técnica base é um refinamento do que o Kurt Stephens sugeriu. Ele não apenas elimina os vazamentos nesta única linha:
loop {@x=callcc{|c|c}}
mas também na nossa aplicação robótica multi-threads. Nosso processo Ruby costumava crescer em mais de 20 MB durante um dia de execução. A mesma execução agora fica menor que 10 MB.
Como foi descoberto, os vazamentos são causados por otimizações GCC que interagem muito mal com o conservative GC do Ruby.:
Os vazamentos de memória do garbage collector não são realmente a sua própria culpa. O problema é que a maquina stack "C" está cheia de referências de objetos. A principal razão para isto é que o compilador GCC cria excessivamente grandes stack frames e não inicializa muitos valores neles. Certos construtores "C" utilizados no avaliador de expressões recursivas do interpretador do Ruby geraram especialmente grande e espersosstack frames. A função rb_eval() é o pior criminoso, criando stack frames em Kilobytes para cada chamada de uma função que pode chamar ela mesmo centenas de vezes. Isto resulta em stacks que possuem centenas de Kilobytes, muitas vezes cheio de referências a objetos antigos e mortos que podem nunca sair.
Brent provê alguns patches (para Ruby 1.8.7-patlevel72) que se destinam a corrigir esses problemas.
Testadores relatam aumentos significantes na velocidade com os patches ao rodar aplicações Rails reais. Alguns problemas foram relatadas também, então vejamos até onde isso vai chegar.
Estes patches são outros exemplos da comunidade (Ruby) open source melhorando o MRI. Mod_rails (ou REE) é outro exemplo, que tornou o Garbage Collector do MRI fork-friendly (veja a notícia linkada para uma explicação).
O Desempenho do MRI também pode variar significantemente dependendo em como ele foi compilado.
Você está planejando em ficar com Ruby 1.8.x em 2009? Se sim, quais são as principais razões?