[PATCH] tracedump: add --help and --function-histogram

Zack Rusin zack at kde.org
Sun Sep 11 18:47:20 PDT 2011


On Sunday, September 11, 2011 06:08:34 AM José Fonseca wrote:
> But does the concept of a LLVM pass really fit well here?
> 
> First, traces can be huge and in general won't fit in memory, so
> passing over the full trace over and over again is inefficient due to
> the need to re-read & re-decompress from disk. An architecture where
> all these things you seek are done simultaneously on a single pass is
> better.

Yea, I don't think passes should ever be allowed to modify the trace. It 
doesn't seem to be very useful to have something modify the trace 
automatically. The passes should just gather info about each individual call, 
do some analysis and present the results via some human readable text/image on 
the exit. 

> Second, there is not much value in rewriting an improved trace (other
> than maybe a validating benchmark). The final goal is to provide a
> detailed report to the user so that the user can go then modify his
> application accordingly [1].

Yea, I definitely agree with this.

> In summary, IMO it would be better to abandon the "multiple
> configurable passes" mindset for the one of "a single pass that
> generates an exhaustive report of how to improve the application".

Yea, maybe. I doubt the code would differ much. With either approach we'd have 
a function call (or the same call inlined) which would dispatch the analysis 
to other functions - histogram, performance analysis, deprecation analysis, 
state checks, etc. It seems like it's just a matter of whether all those 
functions called from the dispatch are called via the same interface and 
whether one can disable/enable any of them.

If we had a way of disabling those passes, then we could do most of the other 
things using the same interface, e.g. snapshot generation and performance 
timing. The dispatch function would just need to know whether a function/pass 
needs to be invoked on every call, end of a frame and whether it needs state. 
But tbh I'm not sure if that'd be significantly cleaner than what we have right 
now.

z


More information about the apitrace mailing list