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

[Katia Aresti]

Hi Sebastien,

First thing to say, you impress me with all this work ! Thank you very much
!

I've been working with Scala for almost three years, and I really
appreciate the functional code style. This involves the use of Optionals
among other things you mention like map, flapMap etc. Looking at the
performance test, it seems Optionals are not an issue, so it's more a
matter of coding style and design in most of the cases.
After my experience with scala, I believe that if Optional do indeed avoid
NullpointerException, they introduce NoSuchElemenException. Because the
coding style with functional programming is more than a matter of Optionals
Yes or No. It's very different from imperative programming and this will be
hard to do really "as it should" in infinispan code base. So in the end,
there will be moments where we will be calling "get" to an empty Optional,
leading to the kind of bugs you listed before involving
NullPointerException. At least, this is the case in my experience,
specially coming from years of Java coding and with such a huge code base.
But I think it's good to use Optionals, specially on return types (not in
method parameters).

So 1+ to use Optionals, and  +1 to decide clearly how and when and
following which coding style rules we should introduce them in our public
APIs, internal APIs and codebase in general.

My 2 cents,

Katia




On Thu, May 18, 2017 at 1:30 PM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> 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>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170518/420480cd/attachment.html