Yeah, I know, but it was more of a lament. Although - if somebody is producing so much JSON for you that you need to care about the speed of parsing it, wouldn't it make sense for both of you to agree on a more efficient format? I mean they would probably save money too on generating it..
Unless you are at either a very large scale, or a really small "embedded" scale, I think the time spent engineering a different interchange format would dwarf the savings from it, especially when you consider that the "bottleneck" of development is almost always the developers, and pulling them off to re-implement another format is time that they don't get to spend on the actual product.
There already exist formats other than JSON for data exchange. This wouldn't require reengineering; just integration with an existing library that meets your licensing needs.
I'd just like to point out that it's still engineering to re-implement a library into your code (it's a bit of a sore spot with me... I've been told to "just use a library it shouldn't take any time at all" in the past, and apparently I'm still not over it!)
But regardless, it's still a non-zero amount of work, and in my experience choosing a mutual format isn't always a simple meeting...
Not to mention that if JSON is still needed elsewhere in your system (either internally, or externally with others) all you've done is add complexity to your application and spend developer time all for some savings on parsing speed.
But you already accepted the cost of this by playing this game - this particular library is in C, which might be an effort to integrate with a different programming language.
On the other hand, there are CBOR or MsgPack libraries that are fast and native for many languages.
