I'll admit to only having skimmed much of this article, but that's a lot of words to say this:
"It turns out that the MRI Ruby 1.9 interpreter is optimized to handle strings containing 23 characters or less more quickly than longer strings."
The rest of the article seems to back that some with benchmarking numbers that suggest allocating a 23 character string is about 50% faster than allocating a 24 character string, which in this particular test worked out to about 200 milliseconds difference in the time it takes to allocate 1 MILLION strings, which makes the time savings about 0.2 picoseconds (200 nanoseconds) per allocation if I remember my SI units right.
It is also a nice introduction to C for rubyists -- it explains the basic ruby c object model and how different kinds of strings are laid out in memory and the implications that has on performance. Ultimately, the author shares your conclusion.
Comments
I'll admit to only having skimmed much of this article, but that's a lot of words to say this:
"It turns out that the MRI Ruby 1.9 interpreter is optimized to handle strings containing 23 characters or less more quickly than longer strings."
The rest of the article seems to back that some with benchmarking numbers that suggest allocating a 23 character string is about 50% faster than allocating a 24 character string, which in this particular test worked out to about 200 milliseconds difference in the time it takes to allocate 1 MILLION strings, which makes the time savings about 0.2 picoseconds (200 nanoseconds) per allocation if I remember my SI units right.
It is also a nice introduction to C for rubyists -- it explains the basic ruby c object model and how different kinds of strings are laid out in memory and the implications that has on performance. Ultimately, the author shares your conclusion.
200ms / 1million = 200 nanoseconds, yes, but that's 0.2 microseconds. If you really want it in picoseconds, it's 200000 of those.