Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!news.glorb.com!postnews.google.com!news2.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail
NNTP-Posting-Date: Sun, 25 Sep 2011 11:30:11 -0500
Date: Sun, 25 Sep 2011 09:30:07 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: Bulk Array Element Allocation, is it faster?
References: <j5lvf0$bhl$1@news.albasani.net> <Ypydnd8C3rt7G-PTnZ2dnUVZ_iydnZ2d@earthlink.com> <9e8fplF19bU1@mid.individual.net> <j5n3qv$dbo$1@news.albasani.net> <9e8kdhF6lmU1@mid.individual.net> <j5ncco$hl$1@news.albasani.net> <j5ncqi$1hv$1@news.albasani.net>
In-Reply-To: <j5ncqi$1hv$1@news.albasani.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <NvudnSfJfcOOyuLTnZ2dnUVZ_tadnZ2d@earthlink.com>
Lines: 46
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 70.230.204.200
X-Trace: sv3-WeBjMxa5PF8UJYhbywbiB2is4pXywD42t4zHEOIRctHsgTv9qsE5s52omCvRNprMmhdb+5D5g63F1DQ!VUFen7gDkRi7GQkuzzDbeccWS27evJAp2ARqgG+x3feQUprntzxOQ3NtxlOl0SqbiYJHFaq/2wsg!XgQQv1D9xFk0JMd2FJQFLKnylZ0Btvd8/hLQvg7WsVL0K8o=
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 2838
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8298

On 9/25/2011 7:11 AM, Jan Burse wrote:
> Jan Burse schrieb:
>> Currently I am planning to change the loop
>> to something like that:
>>
>> Bla[] bla = new Bla[n];
>> for (int i=0; i<n; i++) {
>> bla[i] = createBla();
>> }
>>
>> So that the JIT has less information on what
>> the loop is about, and to do some new
>> measurements. To be fair I would also use
>> createBla() in the lazy scenario. Lets see
>> what happens.
>
> Maybe there is a bug somewhere else in the
> application that leads to the performance loss.
> There are also points in the application where
> some of the bla elements are forcefully set
> to null so as to release Bla objects:
>
> ...
> bla[j] = null;
> ...
>
> I am not sure whether these releases work
> the same in the bulk and the lazy version of
> the code. Need to check first.
>
> So measurements have already shown that the
> release gives some gain, measurements where
> 16000 ms vs. 9600 ms. The release condition
> is more complicated than the lazy new
> condition, but the overhead is compensated
> the overall gain.

I don't think lazy initialization is at all a good idea, even if it made
performance better rather than worse, if there is any condition under
which an array element transitions from non-null to null.

Even if you can prove that the current design never causes
re-initialization, it would be a fragile design under subsequent changes.

Patricia