Benchmarking Ruby String interpolation, concatenation and appending

July 14, 2008 at 23:28

Filed under: Computing — Pistos @ 23:28

I recently came across 6 Optimization Tips for Ruby MRI. One of the tips provided is to use string interpolation instead of concatenation. I set out to determine whether or not we really get any performance boost out of this, and, if so, how much.

My test code makes use of better-benchmark, my Ruby library for statistically correct benchmarking.

Here is a table summarizing the detailed results. By “append” I mean usage of the << operator; by “concatenate” I mean usage of the + operator.

Comparison Improvement Statistically
Significant
Single Quote Append vs. Double Quote Append 0.4% no
Append vs. Interpolation 3.4% no
Two Appends vs. Interpolation 21.0% yes
Concatenation vs. Interpolation 8.4% yes
Two Concatenations vs. Interpolation 29.0% yes
Concatenation vs. Append 7.8% no
Several Concatenations vs. Several Appends 36.3% yes

The first thing to note is that the apparent performance improvement of 3.4% in using interpolation instead of appending is not statistically significant. That is, the data do not provide evidence supporting the claim that interpolation is better (or worse) than appending. However, in fairness, doing two appends makes the difference significant.

We also see that concatenation is slower than appending, as is often cited. But, again, we cannot conclude this is the case when comparing only a single concatenate versus a single append. The difference is only pronounced when doing multiple concatenations or appends in a single Ruby line.

Overall, there appears to be good reason to use interpolation by default, and append or concatenate only under special circumstances. In the end, though, you should be benchmarking larger sections of your code, such as measuring the time taken to render a web page. Doing even a hundred individual concatenations takes just a tiny fraction of a second, and a performance improvement of a few microseconds isn’t going to mean much when you have a large bottleneck elsewhere, such as in your database queries.

Share

Moving on from CVS

July 7, 2008 at 12:34

Filed under: Computing — Pistos @ 12:34

Executive Summary

  • CVS is much worse than modern alternatives
  • Switching SCMs is worth it
  • git is a great alternative
  • CVS is old, inactive and no longer popular
  • No brief status overview
  • Moving or renaming files disjoins history
  • Most recent commit cannot be easily amended
  • Semantic grouping of changes is not recorded
  • Merging is limited
  • Experimentation is discouraged; check-ins become large
  • No way to quickly stash uncommitted changes
  • Cannot commit less than an entire file
  • CVS is unsafe and uncertain

Preamble

This article is a proposal to adopt a source code management system (SCM) better than CVS. The article aims not only to demonstrate the superiority of alternative SCMs, but also to show that the benefits afforded by the alternatives are non-negligible and outweigh the one-time costs of repository conversion and personnel training.

The target audience is twofold: people who decide what SCM to use for a project, team, department or company; and those who work for or with these people, and who would like to propose an alternative to CVS.

This article challenges the statements “CVS is good enough” and “we don’t have any problems with CVS”. It answers the question “Is CVS the best tool for the job?” with an emphatic “No!” (more…)

Share
Powered by WordPress.