On Fri, Jul 1, 2011 at 12:19 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > On Thu, Jun 30, 2011 at 4:45 PM, Simon Willnauer > <simon.willna...@googlemail.com> wrote: >> On Thu, Jun 30, 2011 at 8:50 PM, Dawid Weiss >> <dawid.we...@cs.put.poznan.pl> wrote: >>>> I don't seen any evidence that this is any slower though. >>> >>> You need to run with -client (if the machine is a beast this is tricky >>> because x64 will pick -server regardless of the command-line setting) >>> and you need to be copying generic arrays. I think this can be shown >>> -- a caliper benchmark would be perfect to demonstrate this in >>> isolation; I may write one if I find a spare moment. >> >> this is what I want to see. I don't want to discuss based on some bug >> reported for a non-primitive version of copyOf thats all. >> its pointless to discuss if there is no evidence which I don't see. I >> am happy with arraycopy I would just have appreciated a discussion >> before backing the change out. > > I think the burden of proof here is on Arrays.copyOf. > > Ie, until we can prove (through benchmarking in different envs) that > it can be trusted, we should just stick with System.arraycopy to > reduce the risk.
Mike I think we should do that but the real issue here is what if somebody comes up with any arbitrary method in the future claiming its slow we back out and use the "we think safe way" what if it is actually the other way around and copyOf is optimized by new VMs and the copyarray is slightly slower. If robert would not have reverted this commit we would have not discussed that her at all. I just want to prevent the "we should not do this" it might be a problem in the big picture while the microbenchmark doesn't show a difference. At some point we have to rely on the JVM. Even if we benchmark on all OS with various JVMs we can't prevent jvm bug based perf hits. While there was no bug reported for primitives here we don't have to be afraid of it either. I don't think its saver to use arraycopy at all its just a level of indirection safer but makes development more of a pain IMO. Just my $0.05 > > Mike > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
