tracedump -> libapitrace + tracedump

[José Fonseca]

On Tue, Sep 6, 2011 at 6:17 PM, Alon Levy <alevy at redhat.com> wrote:
> Hi,
>
>  Recently you removed the python tracedumper in favor of maitaing a single
> dump format parsing code base. I think that's a good decision. However, I
> find python writing much easier, so I was thinking of keeping the
> one-code-base idea by splitting tracedump into a library for reading the dump
> (with a C api for easy reuse by python runtime for instance) and having
> tracedump use that. Performance should not be affected. Would a patch like
> this be accepted?

Hi Alon,

Thanks for your feedback and interest.

I have the same feeling towards Python, and I think that exposing the
ability to parse traces to python via an extension module would be
nice.  I'd accept such patch, but beware to not over-engineering such
bindings:

- they must have relatively low-maintenance overhead, or they will
eventually face the same fate as the python trace parsing code
(delete/reverted after getting broken by a major feature elsewhere)

- in particular, maintaining a C API (as opposed to C++) seems a
distraction if the end goal is to operate with Python

- from my experience, Python was extremely slow just to walk over a
big trace directly, so even if you succeed all the above, it's still
difficult to write more than mere proof-of-concept
trace-manipulating-tools in python

Another approach worth considering, is to add support to tracedump to
write every call/arg in JSON format (or another ubiquitous
machine-parseble format), and then base upon that to implement parsing
traces in Python. Essentially, that achieves full flexibility of
python scripting language, without worrying about the re-implementing
trace binary parsing, at the expense of a relative performance
reduction. We could add further tracedump options to grep only
calls/frames of interest. This also has the extra bonus that it could
be easily used by other languages too.


Jose