Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!nx02.iad01.newshosting.com!newshosting.com!news-out.readnews.com!transit3.readnews.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Bulk Array Element Allocation, is it faster? Date: Sun, 25 Sep 2011 11:28:00 -0700 (PDT) Organization: http://groups.google.com Lines: 55 Message-ID: <31815149.2253.1316975280430.JavaMail.geo-discussion-forums@prfp13> References: Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 216.239.45.130 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1316975281 31768 127.0.0.1 (25 Sep 2011 18:28:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 25 Sep 2011 18:28:01 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.239.45.130; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8306 On Sunday, September 25, 2011 10:21:42 AM UTC-7, Jan Burse wrote: > Eric Sosman schrieb: > > 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. ;-) >=20 > What I do in the code has nothing to do with my question. My It has a great deal to do with your question. > question circles only around the following code fragment: >=20 > Bla[] bla =3D new Bla[n]; Here the system does allocate, as you plaintively request, "n*X bytes of sp= ace", where "X" is the size of a pointer. > for (int i=3D0; i bla[i] =3D new Bla(); > } How would you imagine the JIT would optimize this without taking semantics = into account? Each 'Bla' is required to be independently GC-able, you know= . The semantics of 'Bla[]' is not a block of instances; it's a block of re= ferences. How would you bulk allocate a block of references each to a different refer= ence? About the only way is to add a fixed offset to the value pushed into= each successive array element, but that's already what you are doing with = 'new' anyway, so you aren't "optimizing" by doing the same thing.=20 If the 'Bla' constructor is heavyweight, the construction of your n 'Bla' i= nstances will far outweigh any slight overhead in calculating that offset i= ncrease for each array element. I just don't see how you expect to bulk-load n different pointers into that= array. Could you explain that in more detail, please? > And what the JIT does. And not what I am doing in a comparison > with lazy. That is why I started my post with: >=20 > "I just wonder wether [sic] modern JIT [sic] do optimize > Code [sic] of the following form:" >=20 > Please focus on that. Aye, aye, focusing on that, Captain! The answer is "nothing", because the semantics of the operation are such th= at the current mechanism is already quite close to optimal. This is what p= eople have been explaining to you, that you dismissed as irrelevant. --=20 Lew