Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Jan Burse <janburse@fastmail.fm>
Newsgroups: comp.lang.java.programmer
Subject: Re: Bulk Array Element Allocation, is it faster?
Date: Mon, 26 Sep 2011 14:52:29 +0200
Organization: albasani.net
Lines: 63
Message-ID: <j5psid$soa$1@news.albasani.net>
References: <j5lvf0$bhl$1@news.albasani.net> <ke2t77p38ktjf6bi8fvng7mo0a2a0cad8e@4ax.com> <j5mpq6$lra$1@news.albasani.net> <j5n5jo$r2r$1@dont-email.me> <j5nnv6$t23$1@news.albasani.net> <31815149.2253.1316975280430.JavaMail.geo-discussion-forums@prfp13> <j5nv6v$h44$1@news.albasani.net> <25084990.892.1316990596220.JavaMail.geo-discussion-forums@prfb12> <j5oc5u$dpg$1@news.albasani.net> <j5od2h$fbt$1@news.albasani.net> <slrnj8057r.6gl.avl@gamma.logic.tuwien.ac.at>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net a1IOagsF4SboeYDD0hmyQbTUtAzVZdL5qt/FeyEcML7buXopNX0RcHWPyn52V5C5uxCmVQ5ob0eOfuGMRdQ5G0zK20Xclg2hEra/b1NNhwqhwNIH0jH4cEknExPf1O18
NNTP-Posting-Date: Mon, 26 Sep 2011 12:52:29 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="RtQKiDuNZz9jbTslgmb8Of+oVd0xQTgkBr3Pm5AYbwvgitB7vSL2xWXWZNtP2MRlob9f9cR7Nwb5G0uUkvrWXJKsIKqSMzzpmYnju/zVEQh+D4cD5ZWdnuEkKI0G4/1L"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Firefox/6.0.2 SeaMonkey/2.3.3
In-Reply-To: <slrnj8057r.6gl.avl@gamma.logic.tuwien.ac.at>
Cancel-Lock: sha1:iWXMm2TpJBx/SYtHPmKMgGpphkU=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8329

Andreas Leitgeb schrieb:
> Jan Burse<janburse@fastmail.fm>  wrote:
>> Jan Burse schrieb:
>>> So what is going on in the 64bit?
>> Problem resolved! Thanks all for your attention and
>> good advise. Especially persisting in look at the
>> application, there was a bottleneck somewhere else.
>
> If it can be demonstrated within the context of:
>     bulk instanciation in a loop
> versus
>     on-demand instanciation  ("lazy")
> then I'd be curious about where/what that extra bottleneck
> was.
>
>> Dunno why it wasn't seen for 32-bit, ...

Lets assume the following simplified lazy code:

     bla = new Bla[n];
     ..
     if (bla[i]==null)      /* the null test */
        bla[i]=new Bla();   /* the new call */
     ..

I thought that in the lazy version, bla[i] was
maximally n times tested for null. It was
based on the figures I obtained, namely
counting the new calls in bulk and in lazy:

    Bulk: 84'393'262
    Lazy: 81'662'843
    http://www.facebook.com/photo.php?fbid=199117193490169

But the number of new calls is not the
same as the number of null tests, since
a new call is only performed when the null
test succeeds.

So it turned out that there were much more
null tests than new calls. In certain sub
test cases the number can arbirarily go up, so
instead of n tests one might have m*n tests
where m depends on the sub test case, and
is not related to n.

Since my null test is in practice a little
bit more complex in my application and since
m is much above 1 in many of my sub test
cases, the overhead became recognizable.

Meanwhile I could reduce the complexity and
subsequently the frequency of the null test
in my application and the overhead for lazy
has dimished.

There is a little guard which is called like
m times. And then the null test is maximally
n times done. Since the guard is cheap and
since it guards a couple of null tests, the
overhead is now small.

Bye