Re: ClassValue perf?

Michael Haupt Mon, 23 May 2016 06:58:56 -0700

Hi Aleksey,

thanks; comments inlined.

Am 19.05.2016 um 15:57 schrieb Aleksey Shipilev <aleksey.shipi...@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

Benchmark              (CC) (CVC) plain    plevart2 plevart3
CVB.randomAccess       128  1     10.292   11.667   12.686
CVB.randomAccess       128  4     12.413   13.790   13.896
CVB.randomAccess       128  16    14.754   15.963   15.137
CVB.randomAccess       128  256   24.424   25.972   26.411
CVB.randomAccess       1024 1     18.631   19.517   24.339
CVB.randomAccess       1024 4     27.529   27.567   28.890
CVB.randomAccess       1024 16    26.762   31.532   30.088
CVB.randomAccess       1024 256   58.452   45.419   46.016
CVB.sequentialAccess   128  1     11.214   10.739   12.645
CVB.sequentialAccess   128  4     9.317    10.269   10.563
CVB.sequentialAccess   128  16    10.815   9.708    9.787
CVB.sequentialAccess   128  256   18.030   17.278   18.690
CVB.sequentialAccess   1024 1     15.190   12.570   14.429
CVB.sequentialAccess   1024 4     12.529   11.063   13.015
CVB.sequentialAccess   1024 16    9.037    10.024   10.889
CVB.sequentialAccess   1024 256   41.950   38.416   42.341
CVEB.redeployPartition N/A  N/A   148.185  120.086  118.180
CVEB.redeployPartition N/A  N/A   386.839  363.152  380.038
CVEB.redeployPartition N/A  N/A   404.139  264.276  259.995
CVEB.redeployPartition N/A  N/A   1542.053 742.261  757.637

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

Oracle is committed to developing practices and products that help protect the environment

_______________________________________________
mlvm-dev mailing list
mlvm-dev@openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev

Re: ClassValue perf?

Reply via email to