Performance of Pattern Matching for switch (Third Preview)
Jan Lahoda
jan.lahoda at oracle.com
Thu Aug 11 12:26:05 UTC 2022
Hi Jordan,
Thanks for the report. Yes, the performance of various pattern matching
switches is something that we'd like to improve, which is a task that
will probably take a while. Currently, one PR relevant to your benchmark is:
https://github.com/openjdk/jdk/pull/9779
Looking at the benchmark, I have a few comments/questions:
1. I see the "Data" generate the test List of a random length between
1000 and 2000, but as far as I can tell, different testcases will get a
List of a different length. So the testcases are not really the same, as
their input has a different length. Do I miss something here?
2. The actual content of the List is also random, but, again, the
content is not the same for all the testcases, which I believe could
skew the results (consider input data which could have a majority of
Fruit.Apple, and a different set of data which would have a majority of
Fruit.Pear - the tasks to solve this is not the same). The effect of
this is probably limited, though.
3. The test uses 4 threads, but when I run it with this setting, the
error margins are very wide, making the results much less reliable (per
my understanding). Which may be a consequence of the limited amount (4
physical) of cores available on my laptop.
I've tweaked the test to use input data of length 1000 for all cases,
and new Random(0) to generate the data.
The for one thread (testEnhancedSwitch uses the code from PR 9779,
testEnhancedSwitchLegacy uses the code currently in the mainline,
testManualSwitch is the same as in your testcase):
TestEnhancedSwitch.testEnhancedSwitch thrpt 5 95020.310 ±
689.833 ops/s
TestEnhancedSwitch.testEnhancedSwitchLegacy thrpt 5 68175.714 ±
2245.512 ops/s
TestEnhancedSwitch.testManualSwitch thrpt 5 102640.203 ±
2384.880 ops/s
And for two threads:
TestEnhancedSwitch.testEnhancedSwitch thrpt 5 47714.842 ±
2206.843 ops/s
TestEnhancedSwitch.testEnhancedSwitchLegacy thrpt 5 47080.128 ±
1679.960 ops/s
TestEnhancedSwitch.testManualSwitch thrpt 5 41116.334 ±
4938.590 ops/s
(In the multi threaded mode, I wonder how much effect has the use of
ConcurrentHashMap.)
Thanks,
Jan
On 10. 08. 22 12:04, Jordan Zimmerman wrote:
> Hi Folks,
>
> I've been experimenting with Pattern Matching for switch (Third
> Preview). I noticed that the performance of these enhanced switches is
> far worse than manual matching. Is this due to this only being a
> preview and optimizations have yet to be done? Anyway, I thought I'd
> mention what I found as an FYI.
>
> Here's the jmh benchmark I used:
> https://gist.github.com/Randgalt/a68ceee62cd8127431cbe6e7afbfdf44
>
> Here are the results:
>
> Benchmark Mode Cnt Score Error Units
> TestEnhancedSwitch.testEnhancedSwitch thrpt 5 30789.482 ±
> 17667.365 ops/s
> TestEnhancedSwitch.testManualSwitch thrpt 5 44651.612 ±
> 5135.641 ops/s
>
> Cheers.
>
> -Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-dev/attachments/20220811/2584f0e1/attachment-0001.htm>
More information about the amber-dev
mailing list