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