[infinispan-dev] To Optional or not to Optional?

[Sebastian Laskawiec]

Hey!

In our past we had a couple of discussions about whether we should or
should not use Optionals [1][2]. The main argument against it was
performance.

On one hand we risk additional object allocation (the Optional itself) and
wrong inlining decisions taken by C2 compiler [3]. On the other hand we all
probably "feel" that both of those things shouldn't be a problem and should
be optimized by C2. Another argument was the Optional's doesn't give us
anything but as I checked, we introduced nearly 80 NullPointerException
bugs in two years [4]. So we might consider Optional as a way of fighting
those things. The final argument that I've seen was about lack of higher
order functions which is simply not true since we have #map, #filter and
#flatmap functions. You can do pretty amazing things with this.

I decided to check the performance when refactoring REST interface. I
created a PR with Optionals [5], ran performance tests, removed all
Optionals and reran tests. You will be surprised by the results [6]:

Test case
With Optionals [%] Without Optionals
Run 1
<http://perfrepo.mw.lab.eng.bos.redhat.com/reports/tableComparisonReport/5471>
Run
2
<http://perfrepo.mw.lab.eng.bos.redhat.com/reports/tableComparisonReport/5474>
Avg Run 1
<http://perfrepo.mw.lab.eng.bos.redhat.com/reports/tableComparisonReport/5472>
Run
2
<http://perfrepo.mw.lab.eng.bos.redhat.com/reports/tableComparisonReport/5475>
Avg

Non-TX reads 10 threads
Throughput 32.54 32.87 32.71 31.74 34.04 32.89
Response time -24.12 -24.63 -24.38 -24.37 -25.69 -25.03

Non-TX reads 100 threads
Throughput 6.48 -12.79 -3.16 -7.06 -6.14 -6.60
Response time -6.15 14.93 4.39 7.88 6.49 7.19

Non-TX writes 10 threads
Throughput 9.21 7.60 8.41 4.66 7.15 5.91
Response time -8.92 -7.11 -8.02 -5.29 -6.93 -6.11

Non-TX writes 100 threads
Throughput 2.53 1.65 2.09 -1.16 4.67 1.76
Response time -2.13 -1.79 -1.96 0.91 -4.67 -1.88

I also created JMH + Flight Recorder tests and again, the results showed no
evidence of slow down caused by Optionals [7].

Now please take those results with a grain of salt since they tend to drift
by a factor of +/-5% (sometimes even more). *But it's very clear the
performance results are very similar if not the same.*

Having those numbers at hand, do we want to have Optionals in Infinispan
codebase or not? And if not, let's state it very clearly (and write it into
contributing guide), it's because we don't like them. Not because of
performance.

Thanks,
Sebastian

[1] http://lists.jboss.org/pipermail/infinispan-dev/2017-March/017370.html
[2] http://lists.jboss.org/pipermail/infinispan-dev/2016-August/016796.html
[3] http://vanillajava.blogspot.ro/2015/01/java-lambdas-and-low-latency.html
[4]
https://issues.jboss.org/issues/?jql=project%20%3D%20ISPN%20AND%20issuetype%20%3D%20Bug%20AND%20text%20%7E%20%22NullPointerException%22%20AND%20created%20%3E%3D%202015-04-27%20AND%20created%20%3C%3D%202017-04-27
[5] https://github.com/infinispan/infinispan/pull/5094
[6]
https://docs.google.com/a/redhat.com/spreadsheets/d/1oep6Was0FfvHdqBCwpCFIqcPfJZ5-5_YYUqlRtUxEkM/edit?usp=sharing
[7]
https://github.com/infinispan/infinispan/pull/5094#issuecomment-296970673
-- 

SEBASTIAN ŁASKAWIEC

INFINISPAN DEVELOPER

Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170518/0311868f/attachment-0001.html