Binary Communication

I went with json at first to make it easy to interface with stat from any language, so you could easily implement your ui stuff in node or java or c# or whatever.

JSON has rather a lot of overhead, not only in terms of memory (additional characters), but also in terms of instructions, having to build the json adds considerable complexity to the routine that dumps a sample to the stream, not to mention overhead on the decoding side, which clearly limits the ability of any interfacing software to process samples.

Everything is fine when the interval is at some quite large (or normal for other profilers) rate. When we get into the interesting range though, it's a struggle to retrieve data as quickly as stat can generate it.

Maybe, it would be a good idea to either switch to a binary form of communication, or to have it as an option (control) ...

I think I'm leaning in favour of dropping JSON altogether ... I will provide two implementations for decoding the stream, one internal implementation as part of this extension, and one composer package independent of the extension (which will obviously be less efficient). I will also document the binary form such that it should be possible to interface from any language still, just with a little more leg work.

Any thoughts or dissent ?

The issue names no files, tests, or entry points. Start by locating the current JSON sample stream and its encoder and decoder, then define the binary format and whether JSON remains supported. Done would require the binary path, the two decoder implementations described in the issue, and documentation sufficient for other languages to interface with the stream.

Written by the indexing model from the issue text.