>> Oh, and this is only really true for short strings and relatively
>> small amounts of memory. Try doing that whilst say, stream editing a
>> 1TB file.
>
> As I already said, this has proven true in real world reports.

I'd be very impressed if you could afford the ram to do the  
recommended trick with a 1TB file...

I'm not saying you can't speed some things up using these methods, I'm  
saying that any serious and sane requirement for performance will not  
get significant gains from these kinds of suggestions, as this kind of  
stuff is so rarely the real cause of performance loss.

It's about how much indirection you have going on. Where and when does  
puts clear buffers and so on?

>> This whole direction of thought is broken, honestly.
>>
>
> Fine. Don't take the hint.

No worries, I can live with that. :-)

raggi@mbk:~/tmp/bench$ ruby runner.rb 10_000_000
time ruby a.rb 10000000 > /tmp/a

real	0m11.273s
user	0m10.042s
sys	0m0.483s
time ruby b.rb 10000000 > /tmp/b

real	0m7.473s
user	0m3.978s
sys	0m0.743s
time ruby c.rb 10000000 > /tmp/c

real	0m6.366s
user	0m5.403s
sys	0m0.491s
raggi@mbk:~/tmp/bench$ cat c.rb
times = ARGV[0].to_i
times.times { print "hola mundo\n" }


And the above will work with a significant sized stream, and bigger  
sized strings. You'll notice if you did bound check benchmarks, that  
the other solutions have serious issues in various not uncommon bounds.

Whoops.