Comment by lenkite | Hacker News Reader

Comment by lenkite | Hacker News Reader

Parent Full thread

"Rust enums make defining errors so simple with arbitrary payload."

enum variants are overused in Rust and are highly expensive in memory IMHO. One tends to run into problems like: https://github.com/serde-rs/json/issues/635 in Rust projects when used at scale. Value is an enum variant: https://docs.rs/serde_json/latest/serde_json/value/enum.Valu...

Comment from that issue: "For example, ElasticSearch returns a 8,683KB document, I deser it into Value and the next RAM reading gives me delta of 98,484KB of RAM use. That's more than 10x the original size."

Compare that with a similar issue in simdjson (written in C++), where people are complaining about parsing 4GB documents into a tree !!! https://github.com/simdjson/simdjson/issues/128. serde-json has trouble moving a bullock-cart while simdjson is moving a container ship.

I don't like some parts of Zig - I think not having RAII in the language is a terrible mistake. But I do love that anything and everything that can be allocated needs to be passed an allocator. I do think they could have introduced an allocation context for RAII cleanups though instead of forcing the programmer to manually coding defer base cleanups - this is a major source of errors even for advanced programmers.

> Comment from that issue: "For example, ElasticSearch returns a 8,683KB document, I deser it into Value and the next RAM reading gives me delta of 98,484KB of RAM use. That's more than 10x the original size."

I think this is misleading. `serde_json` is designed to parse JSON documents directly into your user-defined structs. Thus the raw `Value` type isn't optimized for direct manipulation.

That said, what do you expect? The `Value` enum has the `Value::Array` variant that contains a `Vec<Value>`, which is 24 bytes in itself. One for the heap pointer, one for the length, and one for the capacity. Because of alignment requirements the enum discriminant must thus also be aligned at the 8-byte boundary. This gives us a 32-byte type.

It is possible to reduce the variant to 16 bytes by making the value type `Box<[Value]>` instead. Ignoring the `Value::Object` variant for a second, that would make `Value` a 24-byte type. However, you've now also made the type immutable. It's a tradeoff. 8 bytes for mutable values.

Again, do remember that deserializing into `Value`s is _not_ the primary path when working with JSON through `serde_json`.

Yes, I fully understand how enum variants are implemented under the hood. My point was in response to the enthusiastic use of enum variants which generally causes excessive memory to be consumed for even moderate inputs. Folks are surprised by this and then re-write their code to avoid enum variants or use pointer tagging.

Enum variants should come with a STRICT warning in the Rust book and Rust reference that their real-world use should be incorporated very carefully. Most proponents of Rust tend to never mention their costs or caveats. They are most certainly NOT a zero-cost abstraction and tend to trip up lots of programmers.

"Thus the raw `Value` type isn't optimized for direct manipulation."

Maybe this statement this should be explicitly mentioned in the documentation: DO NOT USE `serde_json::value::Value` for moderate or large sized JSON inputs in production! Stack overflow answers merrily recommend the use of `Value` to a get a piece of data out.

How else would you implement tagged union? Rust already optimize away the discriminant when its Option<NonZero>

I don't think serde-json has a limit on size. But under some usages it will allocate extra. For example see: https://github.com/serde-rs/json/issues/160#issuecomment-841... 2.4 GB file can be read and parsed with serde.

I mean... if the size of `Value` is a problem, use `ijson`, the very crate that the author reporting the issue developed.

This is more or less a solved problem.

Reply on news.ycombinator.com