«

[Note: parts of this message were removed to make it a legal post.]

A friend recently sent me this article:
http://blog.metasploit.com/2009/03/blog-post.html

In particular, note the perf difference of += vs << :

framework3 $ time ruby -e 'a = "A"; 100000.times { a << "A" }'
>
> real 0m*0.338s*
> user 0m*0.312s*
> sys 0m0.024s
>
> framework3 $ time ruby -e 'a = "A"; 100000.times { a += "A" }'
>
> real 0m*15.462s*
> user 0m*15.321s*
> sys 0m0.068s


Also note:

*Before you run off and change every instance of += to << in your ruby code*,
> it's important to note that the two don't perform the same operation.
> Because ruby does assignment by reference, the latter overwrites any
> variables that point to the one you're operating on while the former leaves
> any references untouched.
>
>
> framework3 $ irb
> >> a = "A"
> => "A"
> >> b = a
> => "A"
> >> a << "B"
> => "AB"
> >> b
> => "AB"

>> c = "C"
> => "C"
> >> d = c
> => "C"
> >> c += "D"
> => "CD"
> >> d
> => "C"
>



Thought I would pass it along...

that's a nice article about some real-world benchmarking. I wish
more people did things like this.

If you'd like a short tutorial, you can look here:
http://on-ruby.blogspot.com/2008/12/...it-better.html

On Wed, Jun 17, 2009 at 11:06 AM, Joshua Ball<> wrote:
> A friend recently sent me this article:
> http://blog.metasploit.com/2009/03/blog-post.html
>
> In particular, note the perf difference of += vs << :
>
> framework3 $ time ruby -e 'a = "A"; 100000.times { a << "A" }'
>>
>> real 0m*0.338s*
>> user 0m*0.312s*
>> sys 0m0.024s
>>
>> framework3 $ time ruby -e 'a = "A"; 100000.times { a += "A" }'
>>
>> real 0m*15.462s*
>> user 0m*15.321s*
>> sys 0m0.068s
>
>
> Also note:
>
> *Before you run off and change every instance of += to << in your ruby code*,
>> it's important to note that the two don't perform the same operation.
>> Because ruby does assignment by reference, the latter overwrites any
>> variables that point to the one you're operating on while the former leaves
>> any references untouched.
>>
>>
>> framework3 $ irb
>> >> a = "A"
>> => "A"
>> >> b = a
>> => "A"
>> >> a << "B"
>> => "AB"
>> >> b
>> => "AB"
>
>>> c = "C"
>> => "C"
>> >> d = c
>> => "C"
>> >> c += "D"
>> => "CD"
>> >> d
>> => "C"
>>
>
>
>
> Thought I would pass it along...
>



--
thanks,
-pate
-------------------------
Don't judge those who choose to sin differently than you do

http://on-ruby.blogspot.com
http://eldersjournal.blogspot.com

Joshua Ball wrote:
> A friend recently sent me this article:
> http://blog.metasploit.com/2009/03/blog-post.html
>
> In particular, note the perf difference of += vs << :

Thanks for the tip.
--
Posted via http://www.ruby-forum.com/.

On Wed, Jun 17, 2009 at 7:29 PM, pat eyler<> wrote:
> that's a nice article about some real-world benchmarking. =A0I wish
> more people did things like this.
If you search the archives you might find a certain Robert preaching,
never to use a +=3D b when sequences were concerned. Do I feel clever
now? No rather stupid.

Appologies for the lengthy code snippets.

Although I fully acknowledge the value of the post and that it might
be a life saver I would like to add that I pretty much have the
feeling that immutable is preferable over mutable.
And it seems that modern VMs (jruby, 1.9, ???) kind of are written
for that programming style. I am also aware that they make micro
benchmarks like the following even less meaningless, but please
consider it just as a Whack On The Head (nonviolently of course).

---------------------------------------------------------
512/19 > cat strings.rb

N =3D 10_000
b =3D "Wassitmean"
require 'benchmark'
Benchmark.bmbm do | bench |
a =3D "Ruby Rules Re Rowld"
bench.report "+=3D" do
N.times do
a +=3D b
end
end
a =3D "Ruby Rules Re Rowld"
bench.report "<<" do
N.times do
a +=3D b
end
end
end

513/20 > jruby -v strings.rb
jruby 1.3.0 (ruby 1.8.6p287) (2009-06-06 6586) (OpenJDK Client VM
1.6.0_0) [i386-java]
Rehearsal --------------------------------------
+=3D 1.256000 0.000000 1.256000 ( 1.191000)
<< 9.384000 0.000000 9.384000 ( 9.384000)
---------------------------- total: 10.640000sec

user system total real
+=3D 23.397000 0.000000 23.397000 ( 23.397000)
<< 52.953000 0.000000 52.953000 ( 52.953000)

ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
Rehearsal --------------------------------------
+=3D 0.360000 0.020000 0.380000 ( 0.40603
<< 1.040000 0.130000 1.170000 ( 1.209839)
----------------------------- total: 1.550000sec

user system total real
+=3D 1.770000 0.230000 2.000000 ( 2.056577)
<< 2.410000 0.240000 2.650000 ( 3.456429)


I believe that I hit the GC in JRuby with the default settings and the
above might be an indication how performing
the short time object allocation is nowadays. Ruby1.9 has enough
memory on my machine to be that fast but still +=3D is faster than <<.

Cheers
Robert


--=20
Toutes les grandes personnes ont d=92abord =E9t=E9 des enfants, mais peu
d=92entre elles s=92en souviennent.

All adults have been children first, but not many remember.

[Antoine de Saint-Exup=E9ry]

On Thu, Jun 18, 2009 at 10:07 AM, Robert Dober<> wrot=
e:

Very interesting benchmarks indeed ARRRGH
Interesting how you can make happen what you want to happen, here are
the correct results
516/23 > ruby -v strings.rb
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
Rehearsal --------------------------------------
+=3D 0.370000 0.010000 0.380000 ( 0.459725)
<< 0.000000 0.000000 0.000000 ( 0.002819)
----------------------------- total: 0.380000sec

user system total real
+=3D 1.800000 0.230000 2.030000 ( 2.145655)
<< 0.010000 0.000000 0.010000 ( 0.003220)

518/25 > jruby -v strings.rb
jruby 1.3.0 (ruby 1.8.6p287) (2009-06-06 6586) (OpenJDK Client VM
1.6.0_0) [i386-java]
Rehearsal --------------------------------------
+=3D 1.350000 0.000000 1.350000 ( 1.283000)
<< 0.023000 0.000000 0.023000 ( 0.023000)
----------------------------- total: 1.373000sec

user system total real
+=3D 25.738000 0.000000 25.738000 ( 25.739000)
<< 0.004000 0.000000 0.004000 ( 0.004000)

No happy surprises here, and BTW if you are bored step by reading my posts =


Apologies
Robert

--=20
Toutes les grandes personnes ont d=92abord =E9t=E9 des enfants, mais peu
d=92entre elles s=92en souviennent.

All adults have been children first, but not many remember.

[Antoine de Saint-Exup=E9ry]

> Ruby1.9 has enough memory on my machine to be that fast
> but still += is faster than <<.

How should that be possible when += creates a new object
whereas << does not?
--
Posted via http://www.ruby-forum.com/.

On Thu, Jun 18, 2009 at 10:52 AM, Marc Heiler<> wrote=
:
>> Ruby1.9 has enough memory on my machine to be that fast
>> but still +=3D is faster than <<.
>
> How should that be possible when +=3D creates a new object
> whereas << does not?
Sorry please see my post above, I completely got lost.
But be careful, it could be possible indeed, object allocation in the
short living object pool could be way cheaper than copying into the
long living object pool. But my benchmark was ridiculous I should have
spotted the mistake.

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



--=20
Toutes les grandes personnes ont d=92abord =E9t=E9 des enfants, mais peu
d=92entre elles s=92en souviennent.

All adults have been children first, but not many remember.

[Antoine de Saint-Exup=E9ry]

> But be careful, it could be possible indeed, object allocation in the
> short living object pool could be way cheaper than copying into the
> long living object pool.
> But my benchmark was ridiculous I should have spotted the mistake.

But this statement is in conflict with what the pickaxe said years
ago about this - as far as I do remember it was said that << is
faster than +=

Now you say that this is perhaps not the case.

All I would like to to know is, if this is the case here:

Is using += faster than << for string objects?

And if it is not, how is your statement about "short living
objects" vs "long living objects" meant to be understood?

Perhaps I am a bit slow, but reading the posts above I got
the impression that you claimed that += is faster than <<
--
Posted via http://www.ruby-forum.com/.

On Thu, Jun 18, 2009 at 7:06 PM, Marc Heiler<> wrote:
Sorry for the confusion

<< is much faster than += in JRuby and YARV

All the rest was speculation which was not worth the bandwith I have
wasted, really bad, sorry.

I will stop speculating about what wonders generational GC might come
up with some day, because I am kind of confusing lots of folks, myself
being my first victim .

Cheers
Robert

On 6/18/09, Robert Dober <> wrote:
> On Thu, Jun 18, 2009 at 7:06 PM, Marc Heiler<> wrote:
> Sorry for the confusion
>
> << is much faster than += in JRuby and YARV
>
> All the rest was speculation which was not worth the bandwith I have
> wasted, really bad, sorry.
>
> I will stop speculating about what wonders generational GC might come
> up with some day, because I am kind of confusing lots of folks, myself
> being my first victim .
>
> Cheers
>
> Robert

One should only apologize if one did something _truly_ wrong

I have a problem with current benchmarks, because I think the data
store of all the factors are limited. For example, if I get 500
different identical CPU's with one tiny difference... they have
different firmware, or different network/graphic cards, etc.; even if
you build with the same options, well -- point being, the article pat
demonstrated us is enlightening, but not all-encompassing.

I tend to think many people forget that little last bit.

Todd