3 ms·

One of the things I don't like about Option[T] in Nim is when you are handed an optional large structure as a function argument, such as "Option[seq[Thing]]" or

One of the things I don't like about Option[T] in Nim is when you are handed an optional large structure as a function argument, such as "Option[seq[Thing]]" or "Option[BigObject]", or those types as fields of an object passed as argument. It works fine, but the act of unwrapping the value inside with x.get copies the large data structure inside to return it. So it's incredibly slow to access the value inside. Even one such access can be unacceptably slow. Receiving the optional itself as a function argument is fast, because Nim passes a pointer for those arguments. The problem is when you need to use the value wrapped inside. Nim encourages "value oriented programming", where things are written as value types, on the assumption that most of the time Nim is able to use temporary read-only aliases to data instead of copies. So this is the style of passing optionals around that I see in typical code. If you have been handed a mutable option ("var Option[..]") that's different. Then you can unwrap the value inside as a mutable as well, which avoids the copy. But you don't tend to be handed a mutable option in a function argument, except from code that was written in an unusual style with performance in mind, and a contract outside the type system: "I'm giving you a var, but only for performance reasons; don't write to it!".

planetis 5y ago
See the lent annotation? No copying involved. Its a hidden pointer. https://nim-lang.github.io/Nim/options.html#get%2COption%5BT%5D https://nim-lang.github.io/Nim/options.html#get%2COption%5BT...
- jlokier 5y ago
  It's a great idea. I really like a lot of Nim's language design, including from a performance perspectice. If only things were implemented as reliably and nicely as the design suggests. I think people like the neat documented language and take for granted that the implementation must have all things that are implied or suggested by the design, when it's not quite up to natural expectations in practice: > @mratsim: As a potential impact, I tried to use options in my RayTracer, but they were 5x slower (not just a couple dozen percents like the iterator issue in #14421) than passing mutable parameter + bool > @araq: Well nobody claimed Option[T] is a lightweight abstraction. > @mratsim: I was misled by Rust code :/ https://github.com/nim-lang/Nim/issues/14420#issuecomment-632886274 https://github.com/nim-lang/Nim/issues/14420#issuecomment-63... Without going into details of any particular problem, I can safely say that when I profile Nim code at runtime, I see a lot more copying than I think was intended by authors. And when I look at the generated C code, I see a lot of temporary objects and redundant copies into and out of them, where it's obvious just from reading a few lines in the C code they are redundant. Not just copies that could be cleverly turned into pointers by lent etc., but temporaries that trivially don't need to be there even without fancy lent/borrowing optimisations.
  - planetis 5y ago
    > And when I look at the generated C code, I see a lot of temporary objects yea it sucks, hopefully it would be fixed soon. https://github.com/nim-lang/Nim/issues/18341 https://github.com/nim-lang/Nim/issues/18341

planetis 5y ago

See the lent annotation? No copying involved. Its a hidden pointer. https://nim-lang.github.io/Nim/options.html#get%2COption%5BT%5D https://nim-lang.github.io/Nim/options.html#get%2COption%5BT...

jlokier 5y ago
It's a great idea. I really like a lot of Nim's language design, including from a performance perspectice. If only things were implemented as reliably and nicely as the design suggests. I think people like the neat documented language and take for granted that the implementation must have all things that are implied or suggested by the design, when it's not quite up to natural expectations in practice: > @mratsim: As a potential impact, I tried to use options in my RayTracer, but they were 5x slower (not just a couple dozen percents like the iterator issue in #14421) than passing mutable parameter + bool > @araq: Well nobody claimed Option[T] is a lightweight abstraction. > @mratsim: I was misled by Rust code :/ https://github.com/nim-lang/Nim/issues/14420#issuecomment-632886274 https://github.com/nim-lang/Nim/issues/14420#issuecomment-63... Without going into details of any particular problem, I can safely say that when I profile Nim code at runtime, I see a lot more copying than I think was intended by authors. And when I look at the generated C code, I see a lot of temporary objects and redundant copies into and out of them, where it's obvious just from reading a few lines in the C code they are redundant. Not just copies that could be cleverly turned into pointers by lent etc., but temporaries that trivially don't need to be there even without fancy lent/borrowing optimisations.
- planetis 5y ago
  > And when I look at the generated C code, I see a lot of temporary objects yea it sucks, hopefully it would be fixed soon. https://github.com/nim-lang/Nim/issues/18341 https://github.com/nim-lang/Nim/issues/18341