3 ms·
Death by a thousand cuts. Let’s take JSON parsing as an example. In the simple case a value like “foo” requires no copying during parsing - it can be parsed wi
by orf 4y ago
Death by a thousand cuts. Let’s take JSON parsing as an example.
In the simple case a value like “foo” requires no copying during parsing - it can be parsed with zero copies. But escaped values like “foo\”bar\”” cause issues. The actual string you want is foo”bar” without the escape slashes. Ok, so for this you need to copy the unescaped string into a scratch buffer somewhere. How big is this buffer? Is the JSON parsing API you’re using flexible enough to let you re-use buffers between calls to avoid extra allocations?
Cool. Now how do you express “this parsed struct field may reference the input bytes or it may reference some scratch space” in a way that’s memory safe? Does your chosen language even support this? What if your internal string representation is platform specific?
Copying uses potentially double the memory but whatever, we are hampered by calling conventions and legacy code and other libraries and opaque unknown callers in different languages and different operating systems and different CPUs. And on top of this mountain of shit you stand and yell “I just want to parse some JSON!”. Screw it. Just always re-allocate and make copies
Now imagine this times by a thousand at every layer of the stack and in every process and every library.
- srcreigh 4y agoIt’d be cool to parse the JSON using the same memory holding the string. Intern the object keys and it should fit
- orf 4y agoYou can do this quite nicely with serde in Rust. It’s elegant. There’s still allocations when needing to unescape values and expand the scratch space, but otherwise it’s all zero copy. You can parse at over a gigabyte a second from stdin without any real tuning.
- zzo38computer 4y ago> Now imagine this times by a thousand at every layer of the stack and in every process and every library. I think that such things are often overused, such as due to using too many dependencies, using badly designed file formats and character encodings, duplication of working, etc.