On 05/19/2016 03:32 PM, Michael Haupt wrote: > It may well be that running the bechmark so few times does not deliver a > stable enough result. I'd like Aleksey to comment on this: is adopting > Peter's code worthwhile given it improves on footprint and reduces code > size and complexity?
Eh, if you pose the question like that, the answer is obviously "yes". I like how Peter's version strips down the ClassValue impl. But, looking at the data, it would seem we are regressing randomAccess with low classValueCount? Benchmark (cCount) (cvCount) Mode Cnt Score Error Units # result-plain.txt randomAccess 1024 1 avgt 10 18.375 ± 0.046 ns/op randomAccess 1024 4 avgt 10 26.755 ± 0.018 ns/op randomAccess 1024 16 avgt 10 26.263 ± 0.024 ns/op randomAccess 1024 256 avgt 10 53.543 ± 0.419 ns/op # result-plevart-03.txt randomAccess 1024 1 avgt 10 23.315 ± 0.053 ns/op randomAccess 1024 4 avgt 10 28.323 ± 0.053 ns/op randomAccess 1024 16 avgt 10 29.514 ± 0.070 ns/op randomAccess 1024 256 avgt 10 45.339 ± 0.035 ns/op This seems to go the other direction Michael was pursuing: optimizing the single-value case. Seems even more pronunciated on low classCount. I'd be more happy if we can at least not regress the performance. If there is a cleaner implementation with the same perf characteristics, I'd be inclined to accept it, of course. > I agree regarding whether there's a point in optimising for single-value > storage whilst maintaining full flexibility. In a scenario where it is > known that only one value will be associated with a class, it's better > to use static fields. Specialized solutions that can use the knowledge about the external condition would always win, given enough effort. The improvements in shared infrastructure are still very welcome, because they break the chicken-and-egg problem: you would not use a shared API if it is slow, and you would not optimize shared API because nobody uses it. Thanks, -Aleksey
signature.asc
Description: OpenPGP digital signature
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
