[ruby-core:45703] Re: A Proposal to Improve the Method String.concat

Posted by Benoit Daloze (Guest) on 2012-06-18 17:55
> ...
> Which means there is no need for optimized repeated String#+, one can
> just #dup the original (if needed) and use #<<(aliased to #concat)
> afterwards.
>
> In numbers:
> ...
> n = 1000000,
> String#concat: 0.88s user 0.01s system 99% cpu 0.896 total
> watershed concatenation: 2.04s user 0.43s system 99% cpu 2.471 total
> ...

Thank You (Benoit Daloze and possibly others) for the answer.

I improved the Ruby version of the tests set
according to Your (Benoit Daloze) observations.
https://github.com/martinvahi/mmmv_notes/tree/master/mmmv_notes/phenomenon_scrutinization/string_concatenation

The measurement results of the version 2 of the tests set:
n=150k, CPU equiv {3,16GHz, 1MiB cache per core}

Ruby test with the plain loop concatenation, version 1.
real    0m14.694s
user    0m13.797s
sys     0m0.844s

Ruby test with the watershed concatenation, version 1
real    0m0.418s
user    0m0.316s
sys     0m0.028s


Ruby test with the watershed concatenation,  version 2 (improved
according to the comments of Benoit Daloze).
real    0m0.403s
user    0m0.320s
sys     0m0.008s


Ruby test with the plain loop concatenation, version 2 (improved
according to the comments of Benoit Daloze).
real    0m0.287s
user    0m0.192s
sys     0m0.016s

I conclude that You (Benoit Daloze) were right:
there's no point of improving the
implementation of the String.concat .

Unfortunately one can still improve the documentation of
the String.+ to save others from what I have just done.

Thank You for the feedback. I found it very helpful.
[e-mail]

-- 
Posted via http://www.ruby-forum.com/.