[WIP] Transmit reports using gob with websockets ...

[2opremio]

... with the intention of caching the gob engines.

Very hacky for now, just a proof of concept.

As an alternative to improve #854

[2opremio]

Unfortunately this doesn't seem to help at all. When running Scope locally (with a single app and probe), it takes double as much CPU as the generated JSON decoders ( #916 ) and I get this app CPU profile:

pprof.172.16.0.3:4040.samples.cpu.011.pb.gz

Surprisingly, even if a single encoding/gob.Decoder is used, compileDec() (which creates the gob engines) takes 40% of the execution time. This isn't expected, since the engines should be cached within the Decoder.

[2opremio]

Surprisingly, even if a single encoding/gob.Decoder is used ...

This is not true. LatestMap, Counters etc ... all provide their own GobEncode()/GobDecode() functions, which in turn create buffers and their own encoders/decoders. Let's see if I can pass the top-level encoder/decoder. I believe this should also help quite a bit with garbage collection.

This is also the case for JSON, which is probably hurting performance in #916 too

[2opremio]

There isn't a way to pass in the same encoder. Using encoding/gob.Register to avoid intermediate representations for ps.Map (11d517a) didn't fly either. I ended up getting:

runtime: goroutine stack exceeds 1000000000-byte limit

In a nutshell, gob not only sucks with used in request-response communications (which admittedly wasn't designed for) but also when you want to serialize intermediate representations of your types/interfaces.

[2opremio]

Closing in favor of #916

[2opremio]

PS: it seems like the Golang maintainers don't have any plans to improve the interface in order to allow more efficient serialization of custom intermediate types. https://groups.google.com/forum/#!topic/golang-nuts/BQsVtMiu0W4