From: Francis Cianfrocca Date: 2006-09-15T21:43:02+09:00 Subject: Re: Benchmark for Ruby ------=_Part_14647_28267439.1158324132414 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 9/15/06, Austin Ziegler wrote: > > I'm not interested in things that require compiler flag tweaks -- > that's far too variant and should be done on a per-system basis. I'm > looking for a benchmark suite that show areas where the implementation > can be improved. I'm not looking for artificially limited benchmarks > where a simple tweak of an operating system option (e.g., ulimit) > enables the benchmark to run or run faster. > > There's the difference. I'm with Austin on this. Raw performance improvements on particular systems are interesting and worth doing and can be achieved in a whole range of good ways. But it would be really interesting to *all* Ruby programmers to understand where the implementation itself falls short (or less provocatively, where it can be improved). I recently went through a ruby-prof exercise with Net::LDAP's search function and I find a whole raft of surprising things. In the first place, there were no "hot spots" where the code was spending a double-digit percentage of its time. But there were a lot of opportunities for 2% and 5% improvements, and they added up to about a 60-70% improvement overall (meaning that a query which used to execute in x time now takes about 0.4x). Some of the surprises: Symbol#=== is really slow. Replace case statements against Symbols with if/then constructions. Accessing hash tables is really slow (no big surprise), so in really hot loops look for an algorithmic alternative. And there a quite a few more. Maybe they ought to be compiled and published. And recently I was discussing GC with Kirk Haines and decided to test my oft-expressed feeling that Ruby performance degrades very rapidly with working-set size. And I turned up some strong hints (perhaps not surprising) that Ruby would be a whole lot faster with generational GC. ------=_Part_14647_28267439.1158324132414--