But since YUICompressor is written in Java it is quite expensive to start. Done in the staging phase, this is bearable even for the the very agile deployment strategy at Booking.com. Nonetheless, we found that this step slows down the development process. When we started experimenting with dynamic compression, it was easier to port the style sheet compressor logic to Perl than addressing the issues in Java. This resulted in the CSS::Compressor module on CPAN.
We were quite pleased when we found that the Perl port of the logic was faster than the original Java implementation. It turns out that the way that string handling was done in Java puts a lot more pressure on memory allocation than what happens when executing the Perl code that replaced it. It won’t be a surprise for anyone that Perl is good at string manipulation.
The average speedup initially measured was over 50% based on running the minification on a set of production files from several days. Due to the start-up overhead of the JVM, Perl’s CSS::Compressor wins more significantly on a shorter running process. For a larger sample, the Perl implementation still saved about 40% of run time compared to the Java code.
Our usual approach to replacing a component such as this is to run old and new side by side, validating the output without using the new code in anger just yet. It turns out that the only difference in results (apart from run times) were problems with the Java version that never manifested in the reimplementation.
Would you like to be a Developer at Booking.com? Work with us!