From: Florian Gilcher <flo@...>
Date: 2009-11-10T21:17:46+09:00
Subject: Re: Good or best way to allocate a large array

Ralph,

Well, that's a minor point. I just reused Roberts examples because
I expected that to be rather clear.

The thing is that an Array of size (300_000*20) already has as many
slots for references. So it's not "initializing references". It just
makes every field of the Array referencing that one BigNum. There is
no allocation or initialization happening in this step.

As you correctly stated, the first example allocs (300_000*20 + 1)
objects. The interesting point in this is that it triggers the
GC more than once, although there is nothing to collect.

Regards,
Florian

On Nov 10, 2009, at 4:30 AM, Ralph Shnelvar wrote:

> Florian,
>
> Again, I am a newbie but ...
>
> What I _think_ you are saying is that the difference between:
>
>
> $ time ruby19 -e 'x=1<<63;Array.new(300_000*20) {1<<63}'
> real       0m4.091s
>
> and
>
> $ time ruby19 -e 'x=1<<63;Array.new(300_000*20) {x}'
> real       0m0.846s
>
>
> is that the first initializes 300_000*20 BigNums and the second  
> initializes 300_000*20 references to a BigNum.
>
> Ralph
>
>
>
>
> Monday, November 9, 2009, 7:32:06 PM, you wrote:
>
> FG> Hi,
>
> FG> You can manually kickstart the GC by using GC.start.
>
> FG>    http://ruby-doc.org/core/classes/GC.html#M003682
>
> FG> Otherwise, AFAIK, the MRI GCs before breaking certain memory  
> barriers,
> FG> but
> FG> don't quote me on that. (I think it does that by counting  
> mallocs and
> FG> starting the GC once a certain number is hit)
>
> FG> This actually explains this behavior:
>
> FG>    $ time ruby19 -e 'x=1<<63;Array.new(300_000*20) {1<<63}'
> FG>    real       0m4.091s
> FG>    user       0m3.430s
> FG>    sys    0m0.361s
>
> FG>    $ time ruby19 -e 'GC.disable; x=1<<63;Array.new(300_000*20)  
> {1<<63}'
>
> FG>    real       0m2.489s
> FG>    user       0m1.845s
> FG>    sys    0m0.565s
>
> FG> But be aware though, that this is not caused by the allocation
> FG> of the array:
>
> FG>    $ time ruby19 -e 'x=1<<63;Array.new(300_000*20) {x}'
>
> FG>    real       0m0.846s
> FG>    user       0m0.735s
> FG>    sys    0m0.049s
>
> FG>    $ time ruby19 -e 'GC.disable; x=1<<63;Array.new(300_000*20)  
> {x}'
>
> FG>    real       0m0.778s
> FG>    user       0m0.710s
> FG>    sys    0m0.052s
>
>
> FG> So, before (knowingly) breaking those limits, it might be an  
> option
> FG> to disable the GC. Handle with care, though.
>
> FG> Regards,
> FG> Florian
>
> FG> On Nov 9, 2009, at 9:05 PM, Ralph Shnelvar wrote:
>
>>> Rick,
>
>>> Ok ... but the point is that the objects are not gc'd when things go
>>> out of scope but, instead, when Ruby needs memory, right?
>
>>> And if you have a huge array with gobs of objects, the gc is gonna
>>> take a while?
>
>>> Ralph
>
>
>
>
>
> -- 
> Best regards,
> Ralph                            mailto:ralphs@dos32.com
>
>

--
Florian Gilcher

smtp:   flo@andersground.net
jabber: Skade@jabber.ccc.de
gpg:    533148E2