Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #8329

Re: Bulk Array Element Allocation, is it faster?

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> (permalink)
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

Show key headers only | View raw


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

Back to comp.lang.java.programmer | Previous | NextPrevious in thread | Next in thread | Find similar


Thread

Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 03:17 +0200
  Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-24 21:37 -0400
    Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 10:39 +0200
  Re: Bulk Array Element Allocation, is it faster? Patricia Shanahan <pats@acm.org> - 2011-09-24 18:41 -0700
    Re: Bulk Array Element Allocation, is it faster? Robert Klemme <shortcutter@googlemail.com> - 2011-09-25 12:57 +0200
      Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 13:38 +0200
        Re: Bulk Array Element Allocation, is it faster? Robert Klemme <shortcutter@googlemail.com> - 2011-09-25 14:16 +0200
          Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 16:04 +0200
            Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 16:11 +0200
              Re: Bulk Array Element Allocation, is it faster? Patricia Shanahan <pats@acm.org> - 2011-09-25 09:30 -0700
            Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-25 10:59 -0400
              Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 17:14 +0200
                Re: Bulk Array Element Allocation, is it faster? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-25 15:26 +0000
                Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 11:02 -0700
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 20:19 +0200
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 20:21 +0200
                Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-25 17:48 -0400
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 00:10 +0200
  Re: Bulk Array Element Allocation, is it faster? Roedy Green <see_website@mindprod.com.invalid> - 2011-09-24 19:05 -0700
    Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-24 23:22 -0700
      Re: Bulk Array Element Allocation, is it faster? Roedy Green <see_website@mindprod.com.invalid> - 2011-09-25 00:23 -0700
        Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 11:17 -0700
        Re: Bulk Array Element Allocation, is it faster? Joshua Cranmer <Pidgeot18@verizon.invalid> - 2011-09-25 14:00 -0500
    Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 10:47 +0200
      Re: Bulk Array Element Allocation, is it faster? Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-25 08:07 -0400
        Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 19:21 +0200
          Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 19:41 +0200
          Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 11:28 -0700
            Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 21:25 +0200
              Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-25 23:50 +0200
              Re: Bulk Array Element Allocation, is it faster? Lew <lewbloch@gmail.com> - 2011-09-25 15:43 -0700
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 01:06 +0200
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 01:21 +0200
                Re: Bulk Array Element Allocation, is it faster? Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-09-26 06:00 +0000
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 14:52 +0200
                Re: Bulk Array Element Allocation, is it faster? Jan Burse <janburse@fastmail.fm> - 2011-09-26 15:02 +0200

csiph-web