ClassValue perf?

[Michael Haupt]

Hi Aleksey,

thanks; comments inlined.

> Am 19.05.2016 um 15:57 schrieb Aleksey Shipilev <aleksey.shipilev at oracle.com>:
> 
> 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.

Of course; I forgot to add "... in spite of the observed performance regressions", and you've answered that.

> 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've ran the unpatched version and Peter's two patches once more. The results are attached (results.txt). They confirm Aleksey's observation.

Regarding the 03 patch (plevart3 column in the results), perfasm output (see http://cr.openjdk.java.net/~mhaupt/8031043/perfasm.zip) suggests the cost is mainly accrued in ConcurrentHashMap. The same is the case for the 02 patch (plevart2 column).

As things stand, I think we can even focus on Peter's 02 patch, as this is the faster of his two proposals (plevart2 column in the results), reduces the footprint, and reduces the implementation complexity. Can anything be done to improve on its performance? (It has slight performance slowdowns for the single-value case as well.)

>> 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.

Nothing to disagree with,

Michael


-- 

 <http://www.oracle.com/>
Dr. Michael Haupt | Principal Member of Technical Staff
Phone: +49 331 200 7277 | Fax: +49 331 200 7561
Oracle Java Platform Group | LangTools Team | Nashorn
Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany

ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
 <http://www.oracle.com/commitment>	Oracle is committed to developing practices and products that help protect the environment

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160523/48a7e3e3/attachment-0002.html>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: results.txt
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160523/48a7e3e3/results-0001.txt>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20160523/48a7e3e3/attachment-0003.html>