Added ability for bcfg2-info to output stats results to a file

[mschwager]

In order to do some more efficient profiling of bcfg2 I added a feature to output the pstats information to a file for later analysis.

[stpierre]

Is there a reason we can't just print this data to stdout and let the user redirect it whereve they want?

[jsbillings]

the current implementation doesn't actually generate the pstats object, which can be queried and printed in a variety of ways. The output, as currently provided by the bcfg2-info profile command, only prints the first 200 lines, ordered by cumulative time, calls and the time. http://docs.python.org/2/library/profile.html#the-stats-class describes the various other ways you can order the statistics.

[stpierre]

Would this be better implemented as an option to select the stats output
type instead?
On Dec 13, 2012 12:19 PM, "Jonathan Billings" notifications@github.com
wrote:

the current implementation doesn't actually generate the pstats object,
which can be queried and printed in a variety of ways. The output, as
currently provided by the bcfg2-info profile command, only prints the first
200 lines, ordered by cumulative time, calls and the time.
http://docs.python.org/2/library/profile.html#the-stats-class describes
the various other ways you can order the statistics.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/56#issuecomment-11351262.

[jsbillings]

I think this certainly can be added as a feature, but there is still value with stowing the stats object away. Once saved, you can look at different views on the same profile without re-running the whole bcfg2-info command.

[stpierre]

Why wouldn't output redirection work for that portion of this feature? It
seems like this is a mashup of two features:

1. The different output format/data.
2. Saving output to a file, which I hope could be accomplished by simple
   redirection
   On Dec 13, 2012 12:34 PM, "Jonathan Billings" notifications@github.com
   wrote:

I think this certainly can be added as a feature, but there is still value
with stowing the stats object away. Once saved, you can look at different
views on the same profile without re-running the whole bcfg2-info command.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/56#issuecomment-11351982.

[jsbillings]

This change generates a file that isn't simply the text that the bcfg2-info profile command generates. It's actually a complex data structure that you need to use the python pstats module to produce the output. The output of the bcfg2-info profile command is rather limited in comparison. Running the bcfg2-info profile command is a boringly tedious command, takes over a minute on my test system, and if I had to use it to generate output for every different permutation of output I'd want to look at, I'd be spending more time twiddling my thumbs than debugging, and there's no guarantee that the second iteration of the profile isn't affected by some other system bottleneck making it useless as a comparison.

For example, to evaluate the stats file generated by this (or the cProfile.py script included in Python), run: python -m pstats build.123456.profile, and it'll bring up an interactive command line where you can set the sorting fields and generate the statistics traces.

Is there some reason you are so against this kind of profiling tool? I've found it rather useful.

[stpierre]

I think we're talking past each other. I think adding better profiling is
great, I just don't see why we need to add a feature to write to a file
when we could add the ability to write any profile data to stdout and let
the shell take care of where that output ultimately winds up.
On Dec 13, 2012 3:36 PM, "Jonathan Billings" notifications@github.com
wrote:

This change generates a file that isn't simply the text that the
bcfg2-info profile command generates. It's actually a complex data
structure that you need to use the python pstats module to produce the
output. The output of the bcfg2-info profile command is rather limited in
comparison. Running the bcfg2-info profile command is a boringly tedious
command, takes over a minute on my test system, and if I had to use it to
generate output for every different permutation of output I'd want to look
at, I'd be spending more time twiddling my thumbs than debugging, and
there's no guarantee that the second iteration of the profile isn't
affected by some other system bottleneck making it useless as a comparison.

For example, to evaluate the stats file generated by this (or the
cProfile.py script included in Python), run: python -m pstats
build.123456.profile, and it'll bring up an interactive command line
where you can set the sorting fields and generate the statistics traces.

Is there some reason you are so against this kind of profiling tool? I've
found it rather useful.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/56#issuecomment-11358845.

[stpierre]

I looked into this a little more, and now I get why you're dumping the stats to a file. I didn't realize that a) dump_stats() could only dump to a file (not even a StringIO object); and b) that the dumped stats are really only useful as a standalone file -- piping a marshaled stats object through something doesn't really make any sense. I would like a couple of fairly minor changes:

• The way the filename is generated is a bit convoluted. Would it be reasonable to just have the user give the actual filename where the output should go? E.g., 'bcfg2-info profile -f /tmp/clients.$(date +%s) clients'
• We should add the same option to the '-p' option, so that stats generated when profiling the entire server process can also be reused.
• The protoype for the call should be:

profile [-o <dir>] <command> <args>

Or, if we change it to just taking a filename:

profile [-f <file>] <command> <args>

Thanks. Sorry I was so thick-headed about this.