[llvm-dev] [XRay][RFC] Tooling for XRay Trace Analysis
David Blaikie via llvm-dev
llvm-dev at lists.llvm.org
Mon Sep 12 09:35:26 PDT 2016
On Sun, Sep 11, 2016 at 10:24 PM Dean Michael Berris <dean.berris at gmail.com>
> > 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>
> > >
> > >
> > >
> > >> 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 (
> 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?
> -- Dean
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev