From: Ralph Shnelvar Date: 2009-11-10T17:00:10+09:00 Subject: Re: Good or best way to allocate a large array 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