Patch with ProfilerDiscard() routine

[GoogleCodeExporter]

Here's a patch which hopefully(see post scriptum) allows to discard 
uninteresting CPU profiling 
data. It basically adds ProfilerDiscard() global function which resets all 
collected up to this 
moment profiling data. This can be especially useful for profiling CPU hot 
spots only.

The typical usage can be as follows:

  ProfilerStart("/tmp/peaks");

  while(true)
  {
    uint64 t0 = get_ms_time();
    //something useful, e.g. a game application loop
    uint64 t1 = get_ms_time();

    uint64 elapsed = t1 - t0;
    if(elapsed > FRAME_NORMAL_DURATION_MS)
      ProfilerFlush();
    else
      ProfilerDiscard();
  }

P.S. The implementation idea doesn't belong to me, I just followed the Craig's 
advice he posted 
on the mailing list :) Furthermore, I'm not sure whether this patch works as 
expected since I 
could not detect the parts of my application which were responsible for 
slowdowns

Original issue reported on code.google.com by pacha.sh...@gmail.com on 5 Jun 2010 at 1:24

Attachments:

• discard.patch

[GoogleCodeExporter]

Thank you for the patch.  It seems straightforward enough.  The one thing I'm 
confused about is your edits to the comments in profiler.h.  Were they wrong 
before?

It would be great to add a unittest case to test this functionality, especially 
since 
you weren't able to manually verify that it works properly.  I think you might 
want 
to edit profiler_unittest.cc to allow an optional flag or something to test 
discarding (or maybe a whole new .cc file?)  Then profiler_unittest.sh can do 
something like
   "$PROFILER1" 100 1 "$TMPDIR/pwhatever1"
   "$PROFILER1" --discard=50 150 1 "$TMPDIR/pwhatever2"
   VerifySimilar pwhatever1 pwhatever2 1

The idea is that the second profiler will run the loop 150 times, but discard 
profiler info from the first 50 runs.  As a result, it should give similar 
numbers to 
the first run.

Original comment by csilv...@gmail.com on 7 Jun 2010 at 5:49

• Added labels: Priority-Medium, Type-Patch

[GoogleCodeExporter]

Regarding comments...something weird happened, I didn't mean to edit them, I'll 
re-upload the patch. Sorry about that :(

Regarding unit tests...I'll look into that and report back here.

Original comment by pacha.sh...@gmail.com on 8 Jun 2010 at 12:59

Attachments:

• discard.patch

[GoogleCodeExporter]

I have the power to undelete, so I did.  Once you upload a new version of the 
patch with unittests, I'll take a look!

Original comment by csilv...@gmail.com on 8 Jun 2010 at 7:09

[GoogleCodeExporter]

Ping -- any news on this?  I'm happy to take a look at a new version of the 
patch.

Original comment by csilv...@gmail.com on 2 Aug 2010 at 4:52

[GoogleCodeExporter]

Oh, sorry about the silence... I have to confess that even with this patch the 
profiling accuracy wasn't good enough for me. Due to the lack of time and 
deadlines pressure at my current job I decided to use the manual 
profiler(http://floodyberry.wordpress.com/2009/10/07/high-performance-cplusplus-
profiling) and currently I'm completely satisfied with it. Sorry :(

Original comment by pacha.sh...@gmail.com on 2 Aug 2010 at 6:25

[GoogleCodeExporter]

No need to apologize -- I'm glad you found a solution that works for you.

I'll keep this open but with a lower priority.  If other folks have a demand 
for this feature and run across this bug post, they can try implementing the 
unittest and then we can look to include it in perftools.

Original comment by csilv...@gmail.com on 2 Aug 2010 at 5:14

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

It's been a year with no demonstrated demand, so I'm closing the bug.

Original comment by csilv...@gmail.com on 31 Aug 2011 at 11:43

• Changed state: WontFix