3 ms·
That's a massive exaggeration. XML is both much more complex (and bug-prone) to parse, and wastes more space. And the problem here wasn't JSON in the first pla
by ilyt 4y ago
That's a massive exaggeration. XML is both much more complex (and bug-prone) to parse, and wastes more space.
And the problem here wasn't JSON in the first place anyway, it was
> The “back” stack is unlimited, meaning we’re saving more and more state until we explode
And storing previous state in serialized string in current state, instead of just having it stored natively. You'd have same problem if you tried to serialize <format> into a field in <format>
- userbinator 4y agoYou'd have same problem if you tried to serialize <format> into a field in <format> Length-delimited formats don't need (exponentially increasing) escaping.
- deepsun 4y agoBut why do you bring XML? The parent is against human-readable formats, and XML is one of them.
- simplotek 4y ago> And the problem here wasn't JSON in the first place anyway Yes it was. They stored state in a huge JSON dump which ended up working like a zip bomb by the way they had to escape a string. This alone resulted in an exponential increase in memory that quickly became a problem. Think about it for a second: would they experience this issue if they stored an in-memory stack per user? They wouldn't. Heck, it seems that they could live with their JSON choice if they replaced '/' with any other inescapable character and converted it back to '/' when reading.
- xigoi 4y agoXML would also have a problem with this: you'd replace < with <, then with &lt;, then with &amp;lt;, … It's not exponential, but still inefficient.
- simplotek 4y agoInefficient is not the same as problematic. They turned what otherwise would be a linear increase in memory usage into an exponential increase, which expectedly resulted in memory exhaustion problems. There are plenty of problems to go around this approach and overall system design, but the weakest link is undoubtedly how JSON was used.