Cost of Option / Some vs null

[Maxime Lévesque]

 Does scalac implement some kind of magic so that
using Option[T]  is as efficient as using nulls ?
Of course Option is a wrapper so the extra cost should
be one thin object. I was just writing a tight loop
and was trying to make it lean and mean. I got tempted
to depart from idiomatic scala here and use a good old null,
it got me wondering if this kind of magic be doable by
the compiler ? (And is it doing it ?)

  Cheers

[Stefan Langer-4]

In my opinion null isn't just against idiomatic scala it just is plain wrong and often results in non robust bug ridden code that just waits to blow up in your face.
To put it another way if it wouldn't be for Java interoperability I would hope to see scalac abandon null.
Actually it would be awesome if the compiler would actually transform any null value into Option.

And no I do not think that it is as efficient as null since null is basically the absense of any type information. (as far as I understand it) and option is an extra object that wraps a value. But unless you can proof in your case that Option is a bottleneck in your case I wouldn't worry about it and take the safety of Option over null anytime.

Just my 2cts.

2009/11/20 Maxime Lévesque <maxime.levesque@...>

 Does scalac implement some kind of magic so that
using Option[T]  is as efficient as using nulls ?
Of course Option is a wrapper so the extra cost should
be one thin object. I was just writing a tight loop
and was trying to make it lean and mean. I got tempted
to depart from idiomatic scala here and use a good old null,
it got me wondering if this kind of magic be doable by
the compiler ? (And is it doing it ?)

  Cheers

[Ismael Juma]

On Thu, 2009-11-19 at 23:57 -0500, Maxime Lévesque wrote:
>
>  Does scalac implement some kind of magic so that
> using Option[T]  is as efficient as using nulls ?

No.

This was mentioned as a possibility at some point, but some people were
upset when an assert checking for null was added to Some and there's
also the question of how to deal with List(null).headOption.

> Of course Option is a wrapper so the extra cost should
> be one thin object. I was just writing a tight loop
> and was trying to make it lean and mean. I got tempted
> to depart from idiomatic scala here and use a good old null,
> it got me wondering if this kind of magic be doable by
> the compiler ? (And is it doing it ?)

In very tight loops, the allocation cost of Option (assuming it doesn't
get elided via escape analysis) could cause a slowdown indeed.

Best,
Ismael

[Viktor Klang]

Allocation elision is something that will start to play a part here soon.

On Nov 20, 2009 9:51 AM, "Ismael Juma" <mlists@...> wrote:

On Thu, 2009-11-19 at 23:57 -0500, Maxime Lévesque wrote: > > Does scalac implement some kind of m...

No.

This was mentioned as a possibility at some point, but some people were
upset when an assert checking for null was added to Some and there's
also the question of how to deal with List(null).headOption.

> Of course Option is a wrapper so the extra cost should > be one thin object. I was just writing a...

In very tight loops, the allocation cost of Option (assuming it doesn't
get elided via escape analysis) could cause a slowdown indeed.

Best,
Ismael

[Ismael Juma]

On Fri, 2009-11-20 at 10:20 +0100, Viktor Klang wrote:
> Allocation elision is something that will start to play a part here
> soon.

Are you talking about HotSpot or scalac -optimise? And what do you mean
by "soon"?

Scalar replacement has been in HotSpot for some releases now, but it's
still very limited and optimisation opportunities are missed when
compared to allocation-free code (relevant for very tight loops).

Best,
Ismael

[phkoester]

Ismael Juma wrote:

> On Fri, 2009-11-20 at 10:20 +0100, Viktor Klang wrote:
>> Allocation elision is something that will start to play a part here
>> soon.
>
> Are you talking about HotSpot or scalac -optimise? And what do you mean
> by "soon"?
>
> Scalar replacement has been in HotSpot for some releases now, but it's
> still very limited and optimisation opportunities are missed when
> compared to allocation-free code (relevant for very tight loops).
>
> Best,
> Ismael

The initial question was good: Does Scala abandon `null' in favor of
`None'? Especially if you make your classes unapply-aware, Options are
the only way to go.

I think that nullness is itself a sort of a value: absence of
information. I'd reckon that 50 % of Java code deals with the question
``null or not null," sounding Shakespearish. So yes, this `Some' and
`None' stuff may be overengineered.

---Phil

[Ismael Juma]

On Fri, 2009-11-20 at 10:40 +0100, Philip Köster wrote:
> The initial question was good: Does Scala abandon `null' in favor of
> `None'?

That was not the initial question. The question was:

"Does scalac implement some kind of magic so that using Option[T]  is as
efficient as using nulls ?"

> I think that nullness is itself a sort of a value: absence of
> information. I'd reckon that 50 % of Java code deals with the question
> ``null or not null," sounding Shakespearish. So yes, this `Some' and
> `None' stuff may be overengineered.

I don't know how you reached that conclusion from what you said above.

Ismael

[phkoester]

> I don't know how you reached that conclusion from what you said above.
>
> Ismael

The only thing I know is that `Option' confuses me any time I encounter
it. The following is poorly memorized, and it may be wrong: If I say
`get' on a Scala map, I might receive a `None' , but if I use
parentheses, I receive an exception. Either way it is, all of that is
hard to memorize, and a cul-de-sac.

Now this is a good example of how libraries should *not* be designed. It
places the burden on the user of a lib, who really just wants to get his
job done and not worry about subleties such as the difference between
`null' and `None'. This imposes a new kind of fuzzy logic leading to
even more if-then-else branches than we really need.

[Viktor Klang]

2009/11/20 Ismael Juma <mlists@...>

On Fri, 2009-11-20 at 10:20 +0100, Viktor Klang wrote:
> Allocation elision is something that will start to play a part here
> soon.

Are you talking about HotSpot or scalac -optimise? And what do you mean
by "soon"?

I'm talking about HotSpot,

I recently read somewhere that escape analysis is going to be improved.

Also, something about stack allocation when scalar replacement cannot be done, but it knows that the reference won't escape.

 

Scalar replacement has been in HotSpot for some releases now, but it's
still very limited and optimisation opportunities are missed when
compared to allocation-free code (relevant for very tight loops).

Best,
Ismael

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

[Ismael Juma]

On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
> Now this is a good example of how libraries should *not* be designed. It
> places the burden on the user of a lib, who really just wants to get his
> job done and not worry about subleties such as the difference between
> `null' and `None'. This imposes a new kind of fuzzy logic leading to
> even more if-then-else branches than we really need.

This leads me to think that you're using it wrong. Option is meant to
help with the if/else problem that one finds with null (and also the
problem that one never knows where null is expected). You may want to
check some tutorials on Option and the various ways you can use it
without having to rely on if/else all the time.

Best,
Ismael

[Ismael Juma]

On Fri, 2009-11-20 at 11:21 +0100, Viktor Klang wrote:
> I'm talking about HotSpot,
> I recently read somewhere that escape analysis is going to be
> improved.

Do you have a link? I posted something about this on Twitter and I'm
curious if it's a different one.

> Also, something about stack allocation when scalar replacement cannot
> be done, but it knows that the reference won't escape.

This I haven't heard about. Do you have a reference?

Best,
Ismael

[Viktor Klang]

2009/11/20 Ismael Juma <mlists@...>

On Fri, 2009-11-20 at 11:21 +0100, Viktor Klang wrote:
> I'm talking about HotSpot,
> I recently read somewhere that escape analysis is going to be
> improved.

Do you have a link? I posted something about this on Twitter and I'm
curious if it's a different one.

I'll try to dig it up and send it to you, can't promise anything though :/

I'm at the "Universal VM" presentation at Devoxx right now, perhaps I can try to ask Alex Buckley afterwards.

 

> Also, something about stack allocation when scalar replacement cannot
> be done, but it knows that the reference won't escape.

This I haven't heard about. Do you have a reference?

Same as above. 

Best,
Ismael

--
Viktor Klang
| "A complex system that works is invariably
| found to have evolved from a simple system
| that worked." - John Gall

Blog: klangism.blogspot.com
Twttr: twitter.com/viktorklang
Code: github.com/viktorklang

[phkoester]

Ismael Juma schrieb:

> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>> Now this is a good example of how libraries should *not* be designed. It
>> places the burden on the user of a lib, who really just wants to get his
>> job done and not worry about subleties such as the difference between
>> `null' and `None'. This imposes a new kind of fuzzy logic leading to
>> even more if-then-else branches than we really need.
>
> This leads me to think that you're using it wrong. Option is meant to
> help with the if/else problem that one finds with null (and also the
> problem that one never knows where null is expected). You may want to
> check some tutorials on Option and the various ways you can use it
> without having to rely on if/else all the time.
>
> Best,
> Ismael
>
>

I read all the tutorials, so please don't talk to me like a was a child,
'cause that is something that really pisses me off and makes me
speechless. I can very well understand why beginners are confused about
the diff between `Option' and the Java-native null value, and I predict
many failures will arise from this basic misunderstanding. A user asked
what the difference was, and you gave no answer but only increased the
confusedness. QED.

[Ricky Clarkson]

There was nothing condescending in what Ismael wrote.

2009/11/20 Philip Köster <philip.koester@...>:

>
>
> Ismael Juma schrieb:
>>
>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>
>>> Now this is a good example of how libraries should *not* be designed. It
>>> places the burden on the user of a lib, who really just wants to get his job
>>> done and not worry about subleties such as the difference between `null' and
>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>> if-then-else branches than we really need.
>>
>> This leads me to think that you're using it wrong. Option is meant to
>> help with the if/else problem that one finds with null (and also the
>> problem that one never knows where null is expected). You may want to
>> check some tutorials on Option and the various ways you can use it
>> without having to rely on if/else all the time.
>>
>> Best,
>> Ismael
>>
>>
>
> I read all the tutorials, so please don't talk to me like a was a child,
> 'cause that is something that really pisses me off and makes me speechless.
> I can very well understand why beginners are confused about the diff between
> `Option' and the Java-native null value, and I predict many failures will
> arise from this basic misunderstanding. A user asked what the difference
> was, and you gave no answer but only increased the confusedness. QED.
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Kevin Wright-4]

Sometimes this is frustrating hard, because the short answer "Option is a monad, using nulls is not" is no more enlightening to most Java devs.

I tend to explain it as "Option is a list constrained to size 0 or 1", this means that you can use expressions like "for every item in the list" and know that they still won't error even if the list is empty.

On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster <philip.koester@...> wrote:

Ismael Juma schrieb:

On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:

Now this is a good example of how libraries should *not* be designed. It places the burden on the user of a lib, who really just wants to get his job done and not worry about subleties such as the difference between `null' and `None'. This imposes a new kind of fuzzy logic leading to even more if-then-else branches than we really need.

This leads me to think that you're using it wrong. Option is meant to
help with the if/else problem that one finds with null (and also the
problem that one never knows where null is expected). You may want to
check some tutorials on Option and the various ways you can use it
without having to rely on if/else all the time.

Best,
Ismael

I read all the tutorials, so please don't talk to me like a was a child, 'cause that is something that really pisses me off and makes me speechless. I can very well understand why beginners are confused about the diff between `Option' and the Java-native null value, and I predict many failures will arise from this basic misunderstanding. A user asked what the difference was, and you gave no answer but only increased the confusedness. QED.

[Ismael Juma]

On Fri, 2009-11-20 at 11:36 +0100, Philip Köster wrote:
> I read all the tutorials, so please don't talk to me like a was a child,

I did not. I simply said that if you believe that the usage of Option
leads to more if/else than using null, then maybe you're not using it in
the idiomatic way. I don't see why you'd interpret it the way you did.

> A user asked what the difference was, and you gave no answer but only increased the
> confusedness.

He did not ask that. He was interested in the performance issues of
using Option in tight loops (as I stated in the previous message
already).

Best,
Ismael

[Ricky Clarkson]

I introduced Option at work in some Java code for builders; basically,
a builder would have a number of parameters, Param<Long>,
Param<Boolean>, etc.  Option would let you have Param<Option<Long>> to
specify an optional parameter, rather than having to write a separate
OptionalParameter class and have code duplication everywhere.

Other than that, I said it was a smarter null, as you could not
dereference it without being aware that it may contain nothing.  I
ended up implementing a new Option type in our codebase, though with
what I think is an interesting addition; my Option.None contains a
String reason.  Yes, Tony, this means it's now a String | T, not a
Nothing | T, so calling it Option is a little dubious.  If every time
I got an NPE I could see *why* the value was null at a glance, that'd
be excellent.  There are far too many return null;s in the codebase;
some of them represent errors, some of them represent that there just
was no result for some reason.

I'm not suggesting Scala's Option changes at all, just detailing an experience.

2009/11/20 Kevin Wright <kev.lee.wright@...>:

> Sometimes this is frustrating hard, because the short answer "Option is a
> monad, using nulls is not" is no more enlightening to most Java devs.
> I tend to explain it as "Option is a list constrained to size 0 or 1", this
> means that you can use expressions like "for every item in the list" and
> know that they still won't error even if the list is empty.
>
> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster <philip.koester@...>
> wrote:
>>
>>
>> Ismael Juma schrieb:
>>>
>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>
>>>> Now this is a good example of how libraries should *not* be designed. It
>>>> places the burden on the user of a lib, who really just wants to get his job
>>>> done and not worry about subleties such as the difference between `null' and
>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>> if-then-else branches than we really need.
>>>
>>> This leads me to think that you're using it wrong. Option is meant to
>>> help with the if/else problem that one finds with null (and also the
>>> problem that one never knows where null is expected). You may want to
>>> check some tutorials on Option and the various ways you can use it
>>> without having to rely on if/else all the time.
>>>
>>> Best,
>>> Ismael
>>>
>>>
>>
>> I read all the tutorials, so please don't talk to me like a was a child,
>> 'cause that is something that really pisses me off and makes me speechless.
>> I can very well understand why beginners are confused about the diff between
>> `Option' and the Java-native null value, and I predict many failures will
>> arise from this basic misunderstanding. A user asked what the difference
>> was, and you gave no answer but only increased the confusedness. QED.
>
>

--
Ricky Clarkson
Java and Scala Programmer, AD Holdings
[phone]
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
Google Wave: ricky.clarkson@...

[Ismael Juma]

On Fri, 2009-11-20 at 11:34 +0100, Viktor Klang wrote:
> I'll try to dig it up and send it to you, can't promise anything
> though :/
>
> I'm at the "Universal VM" presentation at Devoxx right now, perhaps I
> can try to ask Alex Buckley afterwards.

OK, thanks. The stack allocation bit is slightly surprising because
HotSpot engineers have not seemed enthusiastic about the performance
improvement that would come out of that when compared to the existing
allocation fast path.[1]

Ismael

[1] "compiled code has a "fast path" of a few instructions which tries
to bump a high-water mark in the current thread's TLAB, successfully
allocating an object if the bumped mark falls before a TLAB-specific
limit address" from

http://openjdk.java.net/groups/hotspot/docs/HotSpotGlossary.html

[Viktor Klang]

Buckley says John Rose is working on stack allocation. So I guess we need an audience with mr Rose!

On Nov 20, 2009 11:52 AM, "Ricky Clarkson" <ricky.clarkson@...> wrote:

I introduced Option at work in some Java code for builders; basically,
a builder would have a number of parameters, Param<Long>,
Param<Boolean>, etc.  Option would let you have Param<Option<Long>> to
specify an optional parameter, rather than having to write a separate
OptionalParameter class and have code duplication everywhere.

Other than that, I said it was a smarter null, as you could not
dereference it without being aware that it may contain nothing.  I
ended up implementing a new Option type in our codebase, though with
what I think is an interesting addition; my Option.None contains a
String reason.  Yes, Tony, this means it's now a String | T, not a
Nothing | T, so calling it Option is a little dubious.  If every time
I got an NPE I could see *why* the value was null at a glance, that'd
be excellent.  There are far too many return null;s in the codebase;
some of them represent errors, some of them represent that there just
was no result for some reason.

I'm not suggesting Scala's Option changes at all, just detailing an experience.

2009/11/20 Kevin Wright <kev.lee.wright@...>:

> Sometimes this is frustrating hard, because the short answer "Option is a > monad, using nulls is ...

-- Ricky Clarkson Java and Scala Programmer, AD Holdings [phone] Skype: ricky_clarkson Goog...

[phkoester]

As Scott Meyers wrote in his unforgettable book, ``More Effective C++,"
he left no doubt about his basic point: If you want to express
something, express it in the language so anyone can understand it. For
me that was the most fundamental sentence of his books. Transferred to
Java, which has only a very poor understanding of constness, this means:
``If you want to express something as being null, then make it null and
not have it an instance of a contrived made-up class."

Ricky Clarkson schrieb:

> I introduced Option at work in some Java code for builders; basically,
> a builder would have a number of parameters, Param<Long>,
> Param<Boolean>, etc.  Option would let you have Param<Option<Long>> to
> specify an optional parameter, rather than having to write a separate
> OptionalParameter class and have code duplication everywhere.
>
> Other than that, I said it was a smarter null, as you could not
> dereference it without being aware that it may contain nothing.  I
> ended up implementing a new Option type in our codebase, though with
> what I think is an interesting addition; my Option.None contains a
> String reason.  Yes, Tony, this means it's now a String | T, not a
> Nothing | T, so calling it Option is a little dubious.  If every time
> I got an NPE I could see *why* the value was null at a glance, that'd
> be excellent.  There are far too many return null;s in the codebase;
> some of them represent errors, some of them represent that there just
> was no result for some reason.
>
> I'm not suggesting Scala's Option changes at all, just detailing an experience.
>
> 2009/11/20 Kevin Wright <kev.lee.wright@...>:
>> Sometimes this is frustrating hard, because the short answer "Option is a
>> monad, using nulls is not" is no more enlightening to most Java devs.
>> I tend to explain it as "Option is a list constrained to size 0 or 1", this
>> means that you can use expressions like "for every item in the list" and
>> know that they still won't error even if the list is empty.
>>
>> On Fri, Nov 20, 2009 at 10:36 AM, Philip Köster <philip.koester@...>
>> wrote:
>>>
>>> Ismael Juma schrieb:
>>>> On Fri, 2009-11-20 at 11:13 +0100, Philip Köster wrote:
>>>>> Now this is a good example of how libraries should *not* be designed. It
>>>>> places the burden on the user of a lib, who really just wants to get his job
>>>>> done and not worry about subleties such as the difference between `null' and
>>>>> `None'. This imposes a new kind of fuzzy logic leading to even more
>>>>> if-then-else branches than we really need.
>>>> This leads me to think that you're using it wrong. Option is meant to
>>>> help with the if/else problem that one finds with null (and also the
>>>> problem that one never knows where null is expected). You may want to
>>>> check some tutorials on Option and the various ways you can use it
>>>> without having to rely on if/else all the time.
>>>>
>>>> Best,
>>>> Ismael
>>>>
>>>>
>>> I read all the tutorials, so please don't talk to me like a was a child,
>>> 'cause that is something that really pisses me off and makes me speechless.
>>> I can very well understand why beginners are confused about the diff between
>>> `Option' and the Java-native null value, and I predict many failures will
>>> arise from this basic misunderstanding. A user asked what the difference
>>> was, and you gave no answer but only increased the confusedness. QED.
>>
>
>
>