Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail
From: Eric Sosman <esosman@ieee-dot-org.invalid>
Newsgroups: comp.lang.java.programmer
Subject: Re: Bulk Array Element Allocation, is it faster?
Date: Sun, 25 Sep 2011 08:07:48 -0400
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <j5n5jo$r2r$1@dont-email.me>
References: <j5lvf0$bhl$1@news.albasani.net> <ke2t77p38ktjf6bi8fvng7mo0a2a0cad8e@4ax.com> <j5mpq6$lra$1@news.albasani.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 25 Sep 2011 12:08:25 +0000 (UTC)
Injection-Info: mx04.eternal-september.org; posting-host="f8igmItKsWs6nM5YanFxAA"; logging-data="27739"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18NG3TpR292EITIeee4FKLn"
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
In-Reply-To: <j5mpq6$lra$1@news.albasani.net>
Cancel-Lock: sha1:V1t8tI9e4d2854jm72Oc0kdiav8=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8290

On 9/25/2011 4:47 AM, Jan Burse wrote:
> Roedy Green schrieb:
>> new does two things:
>> 1. allocates X bytes of space
>> 2. initialises that block of space to a pattern.
>
> So a dumb translation of the loop would be:
>
> 1. for each i between 0 and n-1
> 1.1 allocates X bytes of space
> 1.2 call the initializer
>
> Then I was more thinking that the loop does the
> following, i.e. is cleverly compiled to:
>
> 1. allocates n*X bytes of space
> 2. for each i between 0 and n-1
> 2.1 call the initializer for location X*i
>
> At least I would hand assembler it like this.
> Saving n-1 calls to the heap allocator.

     Since the heap allocator probably consists of one compare-and-
branch ("Is there enough room?") and one addition ("Advance the
nextFreeAddress pointer"), the savings are unlikely to be large.
This isn't malloc(), you know.

> I was already googling a little bit about the
> compilation techniques found for JIT today, but
> did not yet hit any evidence for clever loop
> allocation, but it is so obvious I really it
> must be done. But maybe it is not done because
> of multi-threading or GC, who knows...

     Note that the semantics of the bulk and lazy allocations
in your original example are quite different.  An "optimization"
that changes the meaning of the code is only a benefit if the
code was wrong to begin with. ;-)

-- 
Eric Sosman
esosman@ieee-dot-org.invalid