Re: Benchmark obsession?

Speed does sometimes matter, even in this kind of micro-benchmarks.
Maybe you're writing a JSON processor, maybe a parser, maybe a math
library. Of course, most times you don't, and you shouldn't care about
being a millisecond faster.

And now I can't not comment on the three examples you brought up.

"Don't use symbols, they can't be garbage collected" – this sounds
like someone who doesn't know what the hell they are doing would say.
If there is *ever* a case where you have created enough symbols to
create a visible memory footprint, you are doing something extremely
wrong. Using symbols where you would use magic constants or enums in
language like C, or as "static" (as in, not dynamically generated, or
limited to a certain number – for example columns of a table in a
database) keys of a hash is perfectly okay and it is near impossible
for this to cause problems with GC (symbol's text is internally only
stored *once*, and symbols are special-cased to avoid memory
indirection in C code and passed around as fake-pointers; only other
class treated like this is Fixnum). In fact, this can lead to a faster
code when you replace constant strings with symbols. (Disclaimer: I
didn't benchmark this.)

"Don't concatenate strings, use string interpolation instead" – I'd
say that in most cases string interpolation is clearer than
concatenating, especially when a lot of ".to_s" calls would have to be
used.

"Don't use Enumerable#inject to build up objects" – I am morally
opposed to using #inject for anything else that actually folding an
array into a single value, which is what is was intended for.
Injecting with an object, as clever as it is, is not clear code.

-- Matma Rex