The code path is hit even for empty strings and short strings, so it may still be worth the extra ~30% overhead. Short strings dominate objects, and it's quite common to see large arrays of objects only using small property names.
Better would be to ensure capacity of 4*sizeof(char) if you really wanted to eliminate menory overhead. Keep in mind that a multiplication on high-end chips usually takes about 3 cycles to complete, vs 1 cycle for an addition. On Thursday, August 14, 2025 at 11:15:55 PM UTC-7 [email protected] wrote: > First off, kudos to the team for the recent json stringify optimizations! > > While looking at the new (and old) code I noticed that the way > <https://github.com/v8/v8/blob/main/src/json/json-stringifier.cc#L2454>the > escaped size of a string is being estimated uses an optimization which > could introduce large memory overhead. I don't think that optimizing away a > multiplication is worth the memory trade off especially when dealing with > serialization of large strings. > > I would recommend that the function uses the proper max estimation of 6x > the string length > > size_t MaxEscapedStringLength(size_t length) { return length * 6; } > > -- > Ledion Bitincka > Co-founder | CTO cribl.io | <https://www.cribl.io>@ledbit > <https://twitter.com/ledbit> > Curious about our products? <https://sandbox.cribl.io/> > > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/v8-dev/2daed2c6-c146-472d-a7f5-879c755fa2cdn%40googlegroups.com.
