On Tue, Feb 03, 2026 at 09:46:33AM +0100, Aleksandar Lazic wrote: > > > This library looks nice but have some points which I would like to > > > discuss. > > > > > > + yyjson looks active maintained vs mjson which looks stalled > > > + in yyjson is JSON Path build in instead of handcrafted JSON Query in > > > mjson > > > > Honestly I don't know the difference :-) > > The biggest difference is the syntax '$.JSON-KEY' vs '/JSON-KEY' for our use > case. The JSON Query can be quite complex but that's not used yet in HAProxy > I assume.
OK but if it's just a matter of syntax, it's probably a detail. > > > 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 > > > > > > What's your opinion on that? > > > > Hmmm I hadn't noticed this. That's a big negative. mjson doesn't need to > > allocate memory, so here we face the risk of allocating unknown amounts > > based on the document's contents, right ? Malloc() is already a bottleneck > > on large systems, it represents up to 2 digits of the percent of CPU time > > used by some SSL libs. I'm seeing that they also implement pools but then > > one needs to implement them by thread otherwise you lose thread safety. > > > > It could be helpful to understand why this lib needs to allocate RAM when > > others do not. We're really trying to stay away from memory allocations on > > the fly as they cause a lot of trouble under load (or even attacks). It > > could be more acceptable to make it work with fixed size buffers even it > > it uses more on average rather than random size based on contents. > > There is also the option to don't use malloc. I think this can also be used > to limit the json parsing size. > > https://github.com/ibireme/yyjson/blob/master/doc/API.md#stack-memory-allocator > > ``` > If the JSON is small enough, you can use stack memory to read or write it. > > Sample code: > > char buf[128 * 1024]; // stack buffer > yyjson_alc alc; > yyjson_alc_pool_init(&alc, buf, sizeof(buf)); > > yyjson_doc *doc = yyjson_read_opts(dat, len, 0, &alc, NULL); > ... > yyjson_doc_free(doc); // this is optional, as the memory is on stack > > ``` OK so maybe it can work with a pool area passed to the function which then calls yyjson_alc_pool_init(). We still don't know what order of magnitude is needed nor for how long. In their example they use 128kB from the stack, which is huge, but on the other hand if it only lasts for the time the converter is called, and released immediately after, it's totally acceptable from a pool. The only thing is that code that needs 128kB of context to work does quite a bit of work and will not necessarily be fast, so maybe they do not even need something that big for a 16kB max input. It would be nice to get an idea about how much is needed for a given document size. > I think when in the documentation is mentioned that an recursive parsing > should be avoided should this not be an problem. Yes, though I don't know if you can always avoid them. But anyway if the context is limited, the recursion might also be limited. Willy
