Hi.
On 2026-02-03 (Di.) 11:27, Willy Tarreau wrote:
On Tue, Feb 03, 2026 at 11:01:29AM +0100, William Lallemand wrote:
If we want to replace the library we should be super careful and test a lot,
Absolutely!
it's like changing a regex engine, you would have a lot of compatibility issues
and breakage.
Also another point is that since it's maintained, if it were to be replaced
for a good valid reason, it would be nice to at least have an option to
support one provided by the operating system, because you definitely don't
want to maintain your own copy of something that's already maintained
elsewhere. And if there's some value in adopting a new one (I still don't
understand what it does in addition to what we have), probably that keeping
the option of using one or the other makes sense, like we're doing with zlib
vs slz for example.
My questions for a good integration of yyjson into HAProxy.
Which Memory management handling (pool, dynbuf) can I use based on the doc
of yyjson?
https://github.com/ibireme/yyjson/blob/master/doc/API.md#memory-allocator
I'm honestly not for changing the whole library, if we do have limitation with
the library we should probably do something to extend it or improve it, but I
never saw any report about that.
That's a valid point and the reason for my question.
I agree that we need to be super prudent and in any case that what is
missing must clearly be identified and its implementation evaluated
first. If it's just a matter of performance, I don't remember seeing
any bad report affecting the current parser (beyond the ugly exponent
loop that was fixed), and between CPU and RAM, I'm most always sacrifying
CPU, which can be shared and degrades smoothly.
Willy
So let us agree to keep the mjson library as it is.
Thanks for discussion.
Regards
Aleks
