Performance of

September 2011 ยท 2 minute read

I’ve been meaning to get around to running some performance benchmarks on, but I recently learned a valuable lesson: let the internet do your work for you! :-)

I woke up this morning to find @paulmillr had put together a nice performance benchmark of

Check it out for all the gory details but suffice it to say contracts makes things…slow. This is about what I’d expected since in addition to running the actual contract check we must wrap the contracted functions/objects in a Proxy which runs handlers for each function call or property set/get. Lots of stuff is in the way of the running code.

So does the slow performance of contracts make them unusable? Not necessarily. First off, the compiler can emit JavaScript with contracts completely disabled. So, you can have a “slow” testing/development build with contracts enabled to help track down bugs and a production build with contracts disabled and no slowdown.

In addition, most code is IO bound not CPU bound. So if you want contracts enabled everywhere but still care about performance, be smart about where you apply them. Put them on module boundaries, but don’t put them on tight loops for example.

In sum, contracts are another tool in the software engineer’s toolbox that have advantages (bug squashing) and disadvantages (performance slowdowns when enabled). Use them wisely.