Given Enough Money, All Bugs Are Shallow

- Jeff Atwood
- April 3, 2015
- Uncategorized

Eric Raymond, in The Cathedral and the Bazaar, famously wrote

Given enough eyeballs, all bugs are shallow.

The idea is that open source software, by virtue of allowing anyone and everyone to view the source code, is inherently less buggy than closed source software. He dubbed this “Linus’s Law”.

Insofar

CSS Preprocessor Benchmark

January 27, 2014

Results

The timings for processing a 200 KB file of plain CSS (lower is better):

Sass: 4.9 sec
Sass: 2.5 sec (with warm .sass-cache)
libsass: 0.2 sec
Stylus: 1.7 sec
Rework: 0.2 sec
LESS: 0.5 sec
r.js: 0.2 sec

Libsass (a C++ implementation of Sass) and Rework turn out to be extremely fast.

Background

The speed of your CSS preprocessor is important for developer/designer ergonomics. The preprocessing time measured by this benchmark will typically incur as a delay every time you edit the stylesheet sources and hit reload in the browser. Delays below 0.2 to 0.5 seconds tend to be perceived by the human brain as near-instantaneous. The higher the delay, the higher the mental overhead.

To see how fast preprocessors are, I recently ran an informal benchmark of CSS preprocessors. The benchmark garnered a lot of interest, so I’m posting this write-up in blog form.

Methods

I chose 200 KB of minified ungzipped CSS to simulate a large-ish web application, because that’s approximately the amount that the Yahoo homepage uses.

The file contents were artificially simple:

.x0{color:green;}
.x1{color:green;}
...
.x9999{color:green;}

Benchmark script: css-preprocessor-benchmark.sh

I used Ruby 2.1.0p0, Node 0.10.24, and the master branches of each library (Sass 767c53f, libsass 991bc26, Stylus f539ef0, Rework c60edd3, less.js 281a895, r.js 84f325c).

Discussion

Libsass, Rework, LESS, and r.js came in below the 0.5 second threshold.

Ruby Sass and libsass

Libsass, a re-implementation of Sass in C++, provides a massive (>10x) speed improvement over the original Sass written in Ruby, dropping processing time from 2.5 seconds to 0.2 seconds. It is not quite a drop-in replacement for Sass yet, but it’s getting a lot of development love from Aaron Leung. It might be worth considering for new applications.

People’s biggest worry about libsass seems to be losing the Ruby-based Compass. Perhaps there will be an alternative/re-implementation of Compass that is not Ruby-based. But even without that, we might think about whether the massive speed increase of libsass might justify going without Compass completely.

Given the speed difference, I’d like to suggest that the move from Ruby Sass to libsass is inevitable, and I hope that it will see copious contributions from the community to bring it up to par.

Update: Read Aaron’s notes on the state of libsass.

Others

A surprising contender is the newer Rework coming in at only 0.2 seconds, written in JavaScript but nearly as fast as libsass. LESS.js also did fairly well at 0.5 seconds, while the third JavaScript-based preprocessor, Stylus, fell on the slow side with 1.7 seconds. Perhaps it can be improved though.

I also included r.js, which was the fastest of all. While it’s not strictly a preprocessor, it can inline @import statements, and so it can be used to concatenate your project’s plain CSS files (if you are the minimalist type).

Discuss on Twitter

[…]

Regression of Hash#reject in Ruby 2.1.1

March 10, 2014

In Ruby 2.1.0 or earlier, the reject method in any class that inherits Hash returns an object of its own class. But in Ruby 2.1.1, this behavior has changed accidentally to return always a plain Hash object, not of the inherited class.

class SubHash < Hash
end

p Hash.new.reject { }.class
#=> 2.1.0: Hash, 2.1.1: Hash
p SubHash.new.reject { }.class
#=> 2.1.0: SubHash, 2.1.1: Hash

(To be exact, extra states such as instance variables, etc. aren’t copied either.)

Ruby 2.1.1 shouldn’t include such behavior changes, because with the release of Ruby 2.1.0 we’ve changed our versioning policy, so Ruby 2.1.1 is a patch level release and it shouldn’t break backwards compatibility.

This regression could potentially affect many libraries, one such case is Rails’ HashWithIndifferentAccess and OrderedHash. They are broken: Rails’ issue #14188.

This behavior will be reverted to the 2.1.0 behavior in Ruby 2.1.2, but is expected to be the default behavior for Ruby 2.2.0: Feature #9223. So we recommend to fix your code in order to expect this behavior change.

This accident is caused by one missing backport commit. For more details, see http://blog.sorah.jp/2014/03/10/hash-reject-regression-in-ruby211.

Sorry for any inconvenience, and thank you for your support.

Posted by sorah on 10 Mar 2014

[…]

The Ruby Rails Aggregator