On 12/20/2021 10:01 AM, Jeff Hostetler via GitGitGadget wrote: > Extend Trace2 to provide multiple "stopwatch timers" and "global counters". > 3. Rationale > > Timers and counters are an alternative to the existing "region" and "data" > events. The latter are intended to trace the major flow (or phases) of the > program and possibly capture the amount of work performed within a loop, for > example. The former are offered as a way to measure activity that is not > localized, such as the time spent in zlib or lstat, which may be called from > many different parts of the program. > > There are currently several places in the Git code where we want to measure > such activity -- changed-path Bloom filter stats, topo-walk commit counts, > and tree-walk counts and max-depths. A conversation in [1] suggested that we > should investigate a more general mechanism to collect stats so that each > instance doesn't need to recreate their own atexit handling mechanism. > > This is an attempt to address that and let us easily explore other areas in > the future. > > This patch series does not attempt to refactor those three instances to use > the new timers and counters. That should be a separate effort -- in part > because we may want to retool them rather than just translate them. For > example, rather than just translating the existing four Bloom filter counts > (in revision.c) into Trace2 counters, we may instead want to have a "happy > path timer" and a "sad path timer" if that would provide more insight. I'm excited for these API features. It might be nice to have an RFC- quality series demonstrating how these examples could work with the new API. Makes sense to delay in case there were recommended changes to the API from review in this v1. I also like your attention to thread contexts. I think these timers would be very interesting to use in parallel checkout. CC'ing Matheus for his thoughts on where he would want timer summaries for that feature. I would probably want the per-thread summary to know if we are blocked on one really long thread while the others finish quickly. Within that: what are the things causing us to be slow? Is it zlib? Is it lstat()? Thanks, -Stolee
