3 ms·

Sure, value types are a good thing, but they are no panacea in and of itself. Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating object

by kaba0 3y ago

Sure, value types are a good thing, but they are no panacea in and of itself. Also, any non-toy GC won't be using malloc, e.g. in Java's case allocating objects is barely more expensive than allocating them on the stack: they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it, and clearing the buffer.

riku_iki 3y ago
> they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all. With value objects you have full control and bare-metal-native performance without compromises.
- kaba0 3y ago
  > you have full control and bare-metal-native performance without compromises. Not even you believe that, right? Especially with regards to Go.. Go is closer to JS than to Rust/C++.
  - riku_iki 3y ago
    as soon as you copy your struct by value around, it is easy task for escape analysis to decide to put struct on stack. also, golang has arena API now, and it also makes heap allocations super cheap if you manage to integrate it into app life cycle.
    - lenkite 3y ago
      Golang doesn't have copy elison unlike C++ so in principle you need to leverage the heap escape anyways. Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
      - riku_iki 3y ago
        > Golang doesn't have copy elison unlike C++ so in principle you need to leverage the heap escape anyways. I mean you can pass structs by ref or value around, which makes direct impact will they be on stack or heap. > Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible. Thank you, good to know, looks like big pros in favor of rust as lang for my next project.

by kaba0 3y ago

riku_iki 3y ago

> they use a so-called thread-local allocation buffer, which can be used to allocate new objects in, without expensive synchronization, and the GC can quickly scan it, moving still alive objects out of it yeah, all these logics still have significant overhead, especially memory wise, it is hard to reason when JVM decides to kick that or another optimization or not kick anything at all. With value objects you have full control and bare-metal-native performance without compromises.

kaba0 3y ago
> you have full control and bare-metal-native performance without compromises. Not even you believe that, right? Especially with regards to Go.. Go is closer to JS than to Rust/C++.
- riku_iki 3y ago
  as soon as you copy your struct by value around, it is easy task for escape analysis to decide to put struct on stack. also, golang has arena API now, and it also makes heap allocations super cheap if you manage to integrate it into app life cycle.
  - lenkite 3y ago
    Golang doesn't have copy elison unlike C++ so in principle you need to leverage the heap escape anyways. Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible.
    - riku_iki 3y ago
      > Golang doesn't have copy elison unlike C++ so in principle you need to leverage the heap escape anyways. I mean you can pass structs by ref or value around, which makes direct impact will they be on stack or heap. > Golang's arenas were an experiment that has already been ditched by the maintainer as un-feasible. Thank you, good to know, looks like big pros in favor of rust as lang for my next project.