@Expurple @Huliiiiii

32 is a magic power-of-two number that's more cache line friendly. such that most value variants don't get pessemisied by Array and BigInt. they are using heap allocation anyway, so the penalty is relatively smaller.

if you are concerned about ergonomics, we can add a few From impl.

Yeah, From impls need attention, regardless of boxing. I have some personal TODOs regarding those painful conversions into Value. I'll sort it out and publish later.

32 is a magic power-of-two number that's more cache line friendly.

Sure, but how important is that in practice? I could only find a single open performance-related issue across SeaORM and SeaQuery repos: #259. On the other hand, ergonomics has always been a big issue for me and my team.

I'm vary of micro-optimizing without representative benchmarks. And I doubt that Values are moved or accessed so often that it dominates a separate allocation/deallocation for every Value (of a boxed variant). I'd assume that, most of the time, Values are constucted close to the query, then moved into some internal Vec, then sequentially iterated for serialization, and that's it. Cache lines shouldn't matter for sequential iteration over a Vec, due to pre-fetching.

Btw, the size of Json is also 40, so boxing them won’t make Value smaller.

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024

Btw, the size of Json is also 40, so boxing them won’t make Value smaller.

it's 32. it's interesting that it has enough unused bits that it's still 32 after niche field optimization.

ergonomics has always been a big issue

I think a Value::array<T>() method would solve the issue, then ArrayType don't have to be manually set.

just to say I am not against 40, but inflating it to 40 here brings no additional benefit.

the gain from 24 -> 32 is well worth the memory.

may be we add a few more variants then it becomes 40 inevitably.

Big thanks to both of you! @Huliiiiii @Expurple

Oh, enabling both "with-json" and "with-bigdecimal" breaks niche optimizations.

I agree with Expurple's point — Value is more often used inside a Vec, and the overhead from double heap allocation may not be smaller than the benefit gained from size optimization.

I’ve updated the benchmarks — for inputs with 10 BigDecimal values, performance dropped by about 5–10%. The reduced size of Value didn’t improve the performance of unboxed variants.