Weird Benchmarks.

[JesseOceanMusic]

I'm measuring whole loop of Save&Load + inner validation logic. BUT validation is SAME for all measures.
I'm using nested Data structures (~70 structs).

The data is very specific to gamedev - most of it arrays of data...

sizes uncompressed:
Struct(in c++)           = 169  KB 
BINARY                   = 529  KB
BEVE                     = 4693 KB
JSON PRETTY, indeation 1 = 9799 KB
JSON MINI                = 5513 KB
STRUCT PACK              = 464  KB

sizes compressed lz4 at default settings:
BEVE                     = 60 KB
JSON PRETTY, indeation 1 = 98 KB
JSON MINI                = 64 KB
STRUCT PACK              = 34 KB

[Data     - json small  - SSD]     : min[26.3]    | avg[33.7]    | max[91.1]    : millis
[Data     - json pretty - SSD]     : min[41.2]    | avg[49.3]    | max[76.6]    : millis
[Data     - beve        - SSD]     : min[20.0]    | avg[25.5]    | max[40.6]    : millis
[Data     - struct pack - SSD]     : min[4.2]     | avg[4.9]     | max[8.1]     : millis

[Data     - json small  - RAM]     : min[12.6]    | avg[14.9]    | max[32.6]    : millis
[Data     - json pretty - RAM]     : min[18.7]    | avg[22.3]    | max[39.6]    : millis
[Data     - beve        - RAM]     : min[10.2]    | avg[12.1]    | max[20.0]    : millis
[Data     - struct pack - RAM]     : min[2.9]     | avg[3.8]     | max[10.7]    : millis

[Data LZ4 - json small  - SSD]     : min[14.9]    | avg[17.4]    | max[25.7]    : millis
[Data LZ4 - json pretty - SSD]     : min[22.9]    | avg[27.7]    | max[45.8]    : millis
[Data LZ4 - beve        - SSD]     : min[12.4]    | avg[14.5]    | max[23.2]    : millis
[Data LZ4 - struct pack - SSD]     : min[3.6]     | avg[4.5]     | max[8.9]     : millis

[Data LZ4 - json small  - RAM]     : min[14.3]    | avg[17.0]    | max[26.9]    : millis
[Data LZ4 - json pretty - RAM]     : min[22.7]    | avg[26.3]    | max[37.8]    : millis
[Data LZ4 - beve        - RAM]     : min[11.9]    | avg[14.0]    | max[21.6]    : millis
[Data LZ4 - struct pack - RAM]     : min[3.3]     | avg[4.0]     | max[7.4]     : millis

it's not an ad for struct pack from yalantinglibs... Even though it's crazy fast, almost memcopy speed - making it forward/backward compatible is a lot of boilerplate

[stephenberry]

Did you test untagged BEVE? write_beve_untagged will omit the keys and use BEVE arrays. But, it still doesn't do any compression and is intended to be schema-less like JSON. I do want to add a pure struct packing binary format for C++ in Glaze for maximum performance, but I don't expect to get to it soon. Compatibility is important, and certainly a challenge for complex objects. One issue is that struct packing is dependent on not only compilers but optimization levels, and forcing a particular padding requires #pragma statements that cannot be programmatically generated in C++. Hopefully with future reflection enhancements we will be able to generate structs with specific alignments and padding, which would make this much more stable and compatible across compilers and compiler flags.

[JesseOceanMusic]

No, just the regular BEVE. I just did some benchmarks for myself and decided to share, maybe someone will found it helpful.

The main thing that i get from it - compression in my case is making a lot of sense.

Also i forget to write - all measures were at clang 20 + o3 level optimizations.
Struct pack (yalantinglibs) is very interesting!
[+] Much faster compiling time than Glaze.
[+] Much faster runtime (very close to memset)
[+] Automatic reflection as Glaze.
[-] Does not support migration unless field is std::optional.

I did try Apache Fory/Fury too.
I added 1 macro to globdef and compile time cmake + ninja jumped from 1.5 minutes to 4 minutes.
I did not like it =0

So, Glaze is balanced for my use case.

Probably it will be interesting for you to look into struct pack code base.

Thank you for the library!

[stephenberry]

Yeah, thanks for sharing yalantinglibs's struct pack. I had never looked at this library before. A pure binary approach to copying structures with std::memcpy will provide the best performance, so this is probably what struct pact is doing. It probably isn't truly compatible across compilers, operating systems, and compiler settings, but I'll have to dig in to see if they're making any guarantees.

If you're in a closed system and not saving to load later, then BEVE's untagged approach (serializes structs as arrays without the fields), will get you closer to struct pack performance. You'll also get faster compilation times if you use untagged data, because a lot of the compilation time in Glaze is to optimize the string field hash tables. struct pack isn't doing this because it isn't serializing field names.

And, you're right that compression is probably a good idea, if you're doing any network traffic or care about size.

[JesseOceanMusic]

Thank you!
If i would have energy left - i will try untagged later =0

At this point i'm satisfied with json and having struct pack as fallback lib...