I think Dawid is correct here... so we should change this back? still
personally when I see array clone() or copyOf() it makes me concerned, I
know these are as fast as arraycopy in recent versions, but depending on
which variant is used, and whether you use -server, can be slower... in
general I just don't want us to have performance regressions on say windows
32bit over this stuff, personally I think arraycopy is a sure fire bet every
time, but Ill concede the point that copyOf might not be slower for the
primitive versions... I think in jdk7 we will not have this issue as -client
sorta goes away in favor of the tiered thing? anyway, I think we should
proceed with caution here as far as moving things over to copyOf, I don't
see any evidence that its ever faster, but its definitely sometimes slower.
On Jun 30, 2011 9:12 AM, "Dawid Weiss" <dawid.we...@cs.put.poznan.pl> wrote:
> Arrays.copyOf(primitive) is actually System.arraycopy by default. If
> intrinsics are used it can only get faster. For object types it will
> probably be a bit slower for -client because of a runtime check for
> the component type.
>
> Dawid
>
> On Thu, Jun 30, 2011 at 3:05 PM, Robert Muir <rcm...@gmail.com> wrote:
>> because on windows 32bit at least, -client is still the default on
>> most jres out there.
>>
>> i realize people don't care about -client, but i will police
>> foo[].clone() / arrays.copyOf etc to prevent problems.
>>
>> There are comments about this stuff on the relevant bug reports
>> (oracle's site is down, sorry) linked to this issue.
>> https://issues.apache.org/jira/browse/LUCENE-2674
>>
>> Sorry, I don't think we should use foo[].clone() / arrays.copyOf, I
>> think we should always use arraycopy.
>>
>> On Thu, Jun 30, 2011 at 8:55 AM, Simon Willnauer
>> <simon.willna...@googlemail.com> wrote:
>>> hmm are you concerned about the extra Math.min that happens in the
>>> copyOf method?
>>> I don't how that relates to "intrinsic" and java 1.7
>>>
>>> I don't have strong feelings here just checking if you mix something
>>> up in the comment you put there... I am happy to keep the old and now
>>> current code
>>>
>>> simon
>>>
>>> On Thu, Jun 30, 2011 at 2:42 PM, <rm...@apache.org> wrote:
>>>> Author: rmuir
>>>> Date: Thu Jun 30 12:42:17 2011
>>>> New Revision: 1141510
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1141510&view=rev
>>>> Log:
>>>> LUCENE-3239: remove use of slow Arrays.copyOf
>>>>
>>>> Modified:
>>>>
lucene/dev/trunk/modules/facet/src/java/org/apache/lucene/util/UnsafeByteArrayOutputStream.java
>>>>
>>>> Modified:
lucene/dev/trunk/modules/facet/src/java/org/apache/lucene/util/UnsafeByteArrayOutputStream.java
>>>> URL:
http://svn.apache.org/viewvc/lucene/dev/trunk/modules/facet/src/java/org/apache/lucene/util/UnsafeByteArrayOutputStream.java?rev=1141510&r1=1141509&r2=1141510&view=diff
>>>>
==============================================================================
>>>> ---
lucene/dev/trunk/modules/facet/src/java/org/apache/lucene/util/UnsafeByteArrayOutputStream.java
(original)
>>>> +++
lucene/dev/trunk/modules/facet/src/java/org/apache/lucene/util/UnsafeByteArrayOutputStream.java
Thu Jun 30 12:42:17 2011
>>>> @@ -2,7 +2,6 @@ package org.apache.lucene.util;
>>>>
>>>> import java.io.IOException;
>>>> import java.io.OutputStream;
>>>> -import java.util.Arrays;
>>>>
>>>> /**
>>>> * Licensed to the Apache Software Foundation (ASF) under one or more
>>>> @@ -72,7 +71,11 @@ public class UnsafeByteArrayOutputStream
>>>> }
>>>>
>>>> private void grow(int newLength) {
>>>> - buffer = Arrays.copyOf(buffer, newLength);
>>>> + // It actually should be: (Java 1.7, when its intrinsic on all
machines)
>>>> + // buffer = Arrays.copyOf(buffer, newLength);
>>>> + byte[] newBuffer = new byte[newLength];
>>>> + System.arraycopy(buffer, 0, newBuffer, 0, buffer.length);
>>>> + buffer = newBuffer;
>>>> }
>>>>
>>>> /**
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
