From: Jeff Hostetler Date: Tue, 14 Aug 2018 20:14:00 GMT Subject: Re: [PATCH v4 2/5] unpack-trees: add performance tracing Message-ID: <603037bc-57a4-92a6-9c13-ae5b253d3ba3@jeffhostetler.com> In-Reply-To: On 8/14/2018 2:44 PM, Stefan Beller wrote: > On Tue, Aug 14, 2018 at 11:32 AM Duy Nguyen wrote: >> >> On Tue, Aug 14, 2018 at 8:19 PM Jeff Hostetler wrote: >>> I'm looking at adding code to my SLOG (better name suggestions welcome) >>> patch series to eventually replace the existing git_trace facility. >> >> Complement maybe. Replace, please no. I'd rather not stare at json messages. > > From the sidelines: We'd only need one logging infrastructure in place, as the > formatting would be done as a later step? For local operations we'd certainly > find better formatting than json, and we figured that we might end up desiring > ProtocolBuffers[1] instead of JSon, so if it would be easy to change > the output of > the structured logging easily that would be great. > > But AFAICT these series are all about putting the sampling points into the > code base, so formatting would be orthogonal to it? > > Stefan > > [1] https://developers.google.com/protocol-buffers/ > Last time I checked, protocol-buffers has a C++ binding but not a C binding. I've not had a chance to use pbuffers, so I have to ask what advantages would they have over JSON or some other similar self-describing format? And/or would it be possible for you to tail the json log file and convert it to whatever format you preferred? It seems like the important thing is to capture structured data (whatever the format) to disk first. Jeff