[IshKebab]

Very cool. JSON is clearly a terrible format for this though. I've had great success using SQLite instead. You mentioned binary formats in the video - what other formats are supported? Last I looked the whole chrome://tracing ecosystem was stubbornly stuck with JSON.

[crdavidson]

So, spall has a JSON parser to help all the poor folks stuck using JSON or the chrome devtools profiler, who still need to keep using it.

For everyone doing new things, there's a binary format which is pretty straightforward.

The binary side supports begin and end events, which are defined here: https://github.com/colrdavidson/spall/blob/master/formats/sp...

and the header library mirrors those structs, and chalks out the interfaces around here: https://github.com/colrdavidson/spall/blob/master/spall.h#L2...

Basically, it's a small header, and then events, plopped one after another into the file. Each thread gets a buffer to store events as they come in, and they get written as atomic chunks with fwrite/append, so threads never have to interact directly.

In practice, the overhead for tracepoints with the binary format is super low, depending on the machine on x86, we've seen somewhere between 12-20ns for begin+end trace overhead when compiled with clang (+ occasional disk flush overhead, if you're generating a ton of data). I believe I can get that overhead even smaller to get things nice and lightweight, it's a major goal of mine to be able to trace 10+ million events per second without impacting runtimes significantly, so that bigger projects can be comfortably fully auto-traced.

[IshKebab]

Ah neat. Have you ever used RAD Tools Telemetry (http://www.radgametools.com/telemetry.htm)? I saw Jonathan Blow using it on Youtube once and it looked slick and performant like Spall (and unlike every other open source option).