On Fri, Jul 1, 2011 at 1:47 AM, Simon Willnauer <simon.willna...@googlemail.com> wrote:
> 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. I think we take it case by case? We do need to be careful when using low level ops in Java. In this specific case, we have been almost burned already by Arrays.copyOf, and never by System.arraycopy (that I'm aware of), so we should not cutover until we have some confidence that burning will not occur. Other cases will be different, but this one has enough history that the bias seems clear. > 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. I agree, but generally the burden of proof is on the "new one". Just because we can use Java 1.6 code now doesn't mean we should blindly cutover to new stuff. System.arraycopy is tried & true and we've never hit a perf issue with it, in my memory. > Even if we benchmark on all OS with various JVMs we can't prevent jvm > bug based perf hits. Right, nothing is perfect here; this is just about mitigating risk. We were lucky to have tracked down this slowdown down last time, I think only because Robert was using a -client JVM at the time? > 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. Yes it's a slight hassle (2 extra lines), but if this mitigates risk, it's worth it. That said, if we can convince ourselves that in the primitives only case, Arrays.copyOf has very little risk, then I'm OK w/ using it for those cases. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
