---
604 Arrays.fill(elementData, newSize, size, null);
In performance-critical code I would avoid Arrays.fill because it adds a
bit of overhead (unless it's intrinsified, which I don't think it is).
Last week, I sent few benchmarks I did on array cleaning (zero fill)
comparing
On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourgès
bourges.laur...@gmail.comwrote:
---
604 Arrays.fill(elementData, newSize, size, null);
In performance-critical code I would avoid Arrays.fill because it adds a
bit of overhead (unless it's intrinsified, which I don't think it
Thanks for the research.
It seems like hotspot is recognizing and optimizing fill loops, rather than
intrinsifying calls to Arrays.fill itself (good!).
Anyways, I'd still like the simple fill loops in ArrayList to stay
unchanged. Using Arrays.fill is only slightly more readable. There would
be
On Apr 2 2013, at 10:55 , Martin Buchholz wrote:
Thanks for the research.
It seems like hotspot is recognizing and optimizing fill loops, rather than
intrinsifying calls to Arrays.fill itself (good!).
Why wouldn't doing both be better?
Anyways, I'd still like the simple fill loops in
On Tue, Apr 2, 2013 at 11:24 AM, Mike Duigou mike.dui...@oracle.com wrote:
On Apr 2 2013, at 10:55 , Martin Buchholz wrote:
Thanks for the research.
It seems like hotspot is recognizing and optimizing fill loops, rather
than
intrinsifying calls to Arrays.fill itself (good!).
Why
On Apr 1 2013, at 22:24 , Martin Buchholz wrote:
(Other changes accepted as suggested)
If we are willing to make small incompatible changes, how about when
serializing, storing capacity as the size, so that reconstituted ArrayLists
are pre-trimmed to size?
Yes, I found it strange that
Thanks for the pointer. I had remembered reading this changeset and it has
motivated to use Arrays.fill but I could not have found it.
Mike
On Apr 2 2013, at 02:12 , Patrick Wright wrote:
On Tue, Apr 2, 2013 at 9:27 AM, Laurent Bourgès
bourges.laur...@gmail.comwrote:
---
604
Hello all;
I have posted an updated version of the empty ArrayList and HashMap patch.
http://cr.openjdk.java.net/~mduigou/JDK-7143928/1/webrev/
This revised implementation introduces *no new fields* to either class. For
ArrayList the lazy allocation of the backing array occurs only if the list
Overall, this kind of change seems barely worth doing.
---
This change:
// Let gc do its work
-for (int i = 0; i size; i++)
-elementData[i] = null;
+Arrays.fill(elementData, null);
changes the performance of clear from O(size) to O(capacity), which is bad,
On 03/28/2013 06:38 PM, Mike Duigou wrote:
We have heard back from the performance folks that 85% of empty lists are
created at default size. The proposed patch is going to be revised to do the
inflation trick only for default sized maps which will eliminate the need for a
new field.
Hi Mike,
Have you considered the possibility to re-constitute the initial
capacity from threshold and loadFactor?
Regards, Peter
On 03/27/2013 05:28 PM, Mike Duigou wrote:
I started looking at crafty reuse of size but found too many direct references
to size to attempt getting this right
We have heard back from the performance folks that 85% of empty lists are
created at default size. The proposed patch is going to be revised to do the
inflation trick only for default sized maps which will eliminate the need for a
new field. Something creative involving the use of the existing
On 03/27/2013 06:53 AM, Brian Goetz wrote:
What percentage of the empty lists are default-sized? I suspect it is large,
in which case we could apply this trick only for the default-sized lists, and
eliminate the extra field.
yes, very good idea indeed.
Rémi
On Mar 26, 2013, at 5:25
This seems like a good idea. I will follow up with the performance people to
see if their findings include the requested initial size.
Mike
On Mar 26 2013, at 22:53 , Brian Goetz wrote:
What percentage of the empty lists are default-sized? I suspect it is large,
in which case we could
But you can support any requested initial size if stored in the size field
when list is empty.
On Wed, Mar 27, 2013 at 8:02 AM, Mike Duigou mike.dui...@oracle.com wrote:
This seems like a good idea. I will follow up with the performance people
to see if their findings include the requested
I started looking at crafty reuse of size but found too many direct references
to size to attempt getting this right in the current iteration. Reusing size is
definitely still available to someone who wants to dive in and prepare an
implementation.
Mike
On Mar 27 2013, at 09:17 , Martin
What percentage of the empty lists are default-sized? I suspect it is large,
in which case we could apply this trick only for the default-sized lists, and
eliminate the extra field.
On Mar 26, 2013, at 5:25 PM, Mike Duigou wrote:
Hello all;
This is a review for optimization work that
17 matches
Mail list logo
