ClassValue perf?

[Aleksey Shipilev]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160519/29f261e3/signature.asc>