[PATCH] tracedump: add --help and --function-histogram
jose.r.fonseca at gmail.com
Wed Sep 7 08:40:55 PDT 2011
On Wed, Sep 7, 2011 at 3:48 PM, Zack Rusin <zack at kde.org> wrote:
> On Wednesday, September 07, 2011 05:21:53 AM Alon Levy wrote:
>> trace_parser.cpp | 11 +++++++++++
>> trace_parser.hpp | 5 +++++
>> tracedump.cpp | 20 ++++++++++++++++++--
>> 3 files changed, 34 insertions(+), 2 deletions(-)
> Hi, Alon.
> It's great to see you start contributing to the project. But FWIW I don't
> think this is the right approach.
> Most importantly parser shouldn't do any analysis of the trace. It's just too
> crucial to have it do anything but parsing.
Yes, the right place for this would be a new class derived from
Parser, which also lives in the common library, so that it can be
leveraged by the GUI too, but does not adds overhead for other Parser
> I'm not sure if having trace dump not do trace dumping in certain cases is a
> good idea. I know you did it because there's no better place to put it right
> now but I think a lot better approach would be to create a new tool, e.g.
> tracestats, that would along the histogram dump average/min/max number of
> calls per frame, size of data downloaded by the gpu on each frame and so on.
I envision "git style" CLI, i.e., "<tool> <command> <args> ...", e.g.:
apitrace dump foo.trace
apitrace stats foo.trace
apitrace reenc foo.trace
Whether the individual command are actually separate executable or not
is an implementation detail.
> Finally, tbh, I'd vastly prefer if trace visualization would be done in the
> gui rather than writing tools that keep doing the same thing gui is supposed
> to be doing, but that might be just my preference.
I agree that that's the ideal. But modifying the GUI requires
familiarity with GUI development in general and Qt in particular. I
have neither myself, and can't do more than trivial changes in the
GUI. So I don't oppose having features developed as command line
tools or even scripts, as a prototype or a stepping stone to have them
implemented in the GUI in the future.
In my point of view, script, CLI, and GUI is a list ordered of
increasingly usefulness, but also increasingly development difficulty.
More information about the apitrace