Thanks to @luislavena I got wind of the 1.9.3 TCS experimental build. The promise of faster File operations under Windows was too good to pass up.

My by now legendary ( ;) ) build system (see here, here, here and here in reverse chronological order) is ideal as a realistic benchmark: It’s a production system that relies heavily on File operations, reading, writing files and manipulating paths by the thousands. On Windows!

And it has a rather large performance-measuring test suite.

The environment

Everything runs within a Win7 32bit virtual machine with 2 logical cores and 3Gb of RAM hosted on Win7 64Bit on a quad core Dell Latitude with 8Gb RAM and a 7200 rpm spinning disk. I’ve gone to great lengths to ensure that all tests run under the same conditions (no other processes but VMWare Player, laptop plugged in, sources on the same revision etc.).

###The tests As stated, the system currently runs on 1.9.2p290. I cloned the VM twice and installed 1.9.3p194 on one and the tcs-ruby193_require_fenix_gc_hash_20120413-2 binary on the other. I then run my gem install scripts so that I had freshly compiled gems for each installation.

###Results The Y axis is seconds (yes, that’s an almost half hour build right there - I’d hung my head in shame if it wasn’t really monumental)

The performance improvement that 1.9.3 offers is excellent. Across the board the average improvement from 1.9.2 is 18.7%. This percentage is skewed by the long running builds that are unfortunately affected by the network (due to floating license servers) which might also explain the spike in task 13. For the short tasks that do only file manipulation, file I/O and data conversions the average improvement is over 40% (but with those tasks being short a good chunk is the improvement in require times).

Tasks 4, 10, 13 and 14 are big, full builds that probably trigger the garbage collector but I can’t say for sure without instrumenting the code. 13 and 14 are also dependent on the networked license server and thus there’s an additional factor of unreliability there (builds were ran nights to minimize the danger of the license server croaking, but then there’s a host of servers doing nightly builds as well)

The TCS ruby improves a further 9% on average over the 1.9.3 RubyInstaller but it fares worse on the big slow tasks that are most painful to my team.

My “require” benchmark is rake -T (task #1) and for that the absolute numbers are 10.11s for 1.9.2, 5.37s for 1.9.3 and 4.87s for TCS. Active Record continues to be the worst offender here but the new require logic makes things bearable.

Tasks 6 and 8 are IDE project creation tasks which means file generation using erubis templates with the content being FileList[] instances of manipulated pathnames. The TCS build blows everything out of the water here, being 20% faster than stock 1.9.3 which is in turn 20% faster then 1.9.2. That to me says one thing: “Please,please, please merge the fenix patch into Ruby!”

###Conclusion If you ‘re still on 1.9.2 then you should switch to 1.9.3. Performance is improved across the board.

I won’t yet jump on the TCS bandwagon because of the performance lag in the long tasks but I think that the fenix patch should be merged into Ruby main, the numbers are simply so much better.