[llvm-dev] [XRay][RFC] Tooling for XRay Trace Analysis

[Dean Michael Berris via llvm-dev]

> On 13 Sep 2016, at 02:35, David Blaikie <dblaikie at gmail.com> wrote:
> 
> 
> 
> On Sun, Sep 11, 2016 at 10:24 PM Dean Michael Berris <dean.berris at gmail.com> wrote:
> 
> > On 10 Sep 2016, at 02:05, David Blaikie <dblaikie at gmail.com> wrote:
> >
> >
> >
> > On Thu, Sep 8, 2016 at 11:34 PM Dean Michael Berris <dean.berris at gmail.com> wrote:
> >
> > > On 9 Sep 2016, at 12:35, Dean Michael Berris <dean.berris at gmail.com> wrote:
> > >
> > >
> > >
> > >> On 7 Sep 2016, at 01:21, David Blaikie <dblaikie at gmail.com> wrote:
> > >>
> > >> But I take it you mean (as detailed later) to have a separate format (could be a portable binary format, but currently discussing it as JSON/YAML/etc) that things are converted from that makes them portable?
> > >>
> >
> > One thing worth mentioning on this regard is maybe we can use Flatbuffers (https://google.github.io/flatbuffers/) for the XRay log.
> >
> > For the secondary form (instead of YAML/JSON) or the primary form (the thing compiler-rt writes out)? Or as a form that would cover both use cases without the need to convert from one format to another?
> >
> 
> The primary form -- I suspect the costs here would be acceptable it if it means that we're able to write it once in a single format and make that automatically be durable and portable. I suspect the bit swizzling is going to be dwarfed by the cost of writing to stable media anyway that it could be worth it.
> 
> Now this is still to be measured, but according to the benchmarks (https://google.github.io/flatbuffers/flatbuffers_benchmarks.html) encoding 1M times takes just 3.2 seconds -- ~3 microseconds each, right in the acceptable range of performance for I/O.
> 
> This allows us to write the tool to just deal with flat buffers that just works across platforms.
> 
> Does that make sense?
> 
> Yep. sounds good - though I assume you want to make progress in the interim before any decision on flatbuffers is made?
>  
> 

Yep, I'll assume we don't get to use Flatbuffers yet and proceed with what we have. We can do versioning anyway in the XRay log format so this shouldn't be a huge concern if we do end up using Flatbuffers later.

Cheers

-- Dean