Ropes as an faster alternative to strings?

That does look interesting, but I don't think I can get much of use for it in JSON. The string parsing and serialization is, by now, very very fast. I do suffer from allocation on parsing, but that cost seems to be fairly low (I tried using fixed-size stack allocated buffers as an alternative to object keys, and the gains weren't impressive enough to justify extra work and loss of ergonomics that a simple String provides).

In vast majority of cases I know exactly how long it will be. In fact any string that doesn't contain escaped characters, such as "abc" is made into a slice directly from the input JSON string and from there made into an owned string.

The only place where I do have a growing buffer is in serialization, and while it is a pain there, I do allocate a sufficiently large buffer at the beginning which (due to how Rust internals work) doubles in size every time it's cap is reached, and I'm not sure ropes could help me there as I'd still have to allocate the next cord, and then the next, and so on. The gain there is that you can avoid copying the entire buffer up to the reallocation, but then there is the overhead of handing the rope and indexes and what happens when I want to serialize something that doesn't fit into the current cord and so on.

I'll close the issue for now. As intriguing of an idea as it is, I think there still are other vectors from which I can improve performance, and I should spend more time trying to increase the spec conformance numbers and making the API nicer and this point :).

maciejhirsz / json-rust

Ropes as an faster alternative to strings? #55