git/Documentation/technical/api-trace2.txt, branch v2.41.2

trace2: add global counter mechanism

2022-10-24T19:45:26Z

Add global counters mechanism to Trace2. The Trace2 counters mechanism adds the ability to create a set of global counter variables and an API to increment them efficiently. Counters can optionally report per-thread usage in addition to the sum across all threads. Counter events are emitted to the Trace2 logs when a thread exits and at process exit. Counters are an alternative to `data` and `data_json` events. Counters are useful when you want to measure something across the life of the process, when you don't want per-measurement events for performance reasons, when the data does not fit conveniently within a region, or when your control flow does not easily let you write the final total. For example, you might use this to report the number of calls to unzip() or the number of de-delta steps during a checkout. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

trace2: add stopwatch timers

2022-10-24T19:45:26Z

Add stopwatch timer mechanism to Trace2. Timers are an alternative to Trace2 Regions. Regions are useful for measuring the time spent in various computation phases, such as the time to read the index, time to scan for unstaged files, time to scan for untracked files, and etc. However, regions are not appropriate in all places. For example, during a checkout, it would be very inefficient to use regions to measure the total time spent inflating objects from the ODB from across the entire lifetime of the process; a per-unzip() region would flood the output and significantly slow the command; and some form of post-processing would be requried to compute the time spent in unzip(). Timers can be used to measure a series of timer intervals and emit a single summary event (at thread and/or process exit). Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

api-trace2.txt: elminate section describing the public trace2 API

2022-10-24T19:45:25Z

Eliminate the mostly obsolete `Public API` sub-section from the `Trace2 API` section in the documentation. Strengthen the referral to `trace2.h`. Most of the technical information in this sub-section was moved to `trace2.h` in 6c51cb525d (trace2: move doc to trace2.h, 2019-11-17) to be adjacent to the function prototypes. The remaining text wasn't that useful by itself. Furthermore, the text would need a bit of overhaul to add routines that do not immediately generate a message, such as stopwatch timers. So it seemed simpler to just get rid of it. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

tr2tls: clarify TLS terminology

2022-10-24T19:45:25Z

Reduce or eliminate use of the term "TLS" in the Trace2 code. The term "TLS" has two popular meanings: "thread-local storage" and "transport layer security". In the Trace2 source, the term is associated with the former. There was concern on the mailing list about it refering to the latter. Update the source and documentation to eliminate the use of the "TLS" term or replace it with the phrase "thread-local storage" to reduce ambiguity. Signed-off-by: Jeff Hostetler Signed-off-by: Junio C Hamano

tr2: shows scope unconditionally in addition to key-value pair

2022-08-12T04:05:00Z

When we specify GIT_TRACE2_CONFIG_PARAMS or trace2.configparams, trace2 will prints "interesting" config values to log. Sometimes, when a config set in multiple scope files, the following output looks like (the irrelevant fields are omitted here as "..."): ...| def_param | ... | core.multipackindex:false ...| def_param | ... | core.multipackindex:false ...| def_param | ... | core.multipackindex:false As the log shows, even each config in different scope is dumped, but we don't know which scope it comes from. Therefore, it's better to add the scope names as well to make them be more recognizable. For example, when execute: $ GIT_TRACE2_PERF=1 \ > GIT_TRACE2_CONFIG_PARAMS=core.multipackIndex \ > git rev-list --test-bitmap HEAD" The following is the ouput (the irrelevant fields are omitted here as "..."): Format normal: ... git.c:461 ... def_param scope:system core.multipackindex=false ... git.c:461 ... def_param scope:global core.multipackindex=false ... git.c:461 ... def_param scope:local core.multipackindex=false Format perf: ... | def_param | ... | scope:system | core.multipackindex:false ... | def_param | ... | scope:global | core.multipackindex:false ... | def_param | ... | scope:local | core.multipackindex:false Format event: {"event":"def_param", ... ,"scope":"system","param":"core.multipackindex","value":"false"} {"event":"def_param", ... ,"scope":"global","param":"core.multipackindex","value":"false"} {"event":"def_param", ... ,"scope":"local","param":"core.multipackindex","value":"false"} Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

api-trace2.txt: print config key-value pair

2022-08-12T04:05:00Z

It's supported to print "interesting" config key-value paire to tr2 log by setting "GIT_TRACE2_CONFIG_PARAMS" environment variable and the "trace2.configparam" config, let's add the related docs in Documentaion/technical/api-trace2.txt. Signed-off-by: Teng Long Signed-off-by: Junio C Hamano

usage.c: add a non-fatal bug() function to go with BUG()

2022-06-02T19:51:35Z

Add a bug() function to use in cases where we'd like to indicate a runtime BUG(), but would like to defer the BUG() call because we're possibly accumulating more bug() callers to exhaustively indicate what went wrong. We already have this sort of facility in various parts of the codebase, just in the form of ad-hoc re-inventions of the functionality that this new API provides. E.g. this will be used to replace optbug() in parse-options.c, and the 'error("BUG:[...]' we do in a loop in builtin/receive-pack.c. Unlike the code this replaces we'll log to trace2 with this new bug() function (as with other usage.c functions, including BUG()), we'll also be able to avoid calls to xstrfmt() in some cases, as the bug() function itself accepts variadic sprintf()-like arguments. Any caller to bug() can follow up such calls with BUG_if_bug(), which will BUG() out (i.e. abort()) if there were any preceding calls to bug(), callers can also decide not to call BUG_if_bug() and leave the resulting BUG() invocation until exit() time. There are currently no bug() API users that don't call BUG_if_bug() themselves after a for-loop, but allowing for not calling BUG_if_bug() keeps the API flexible. As the tests and documentation here show we'll catch missing BUG_if_bug() invocations in our exit() wrapper. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

trace2 docs: add missing full stop

2022-05-04T17:31:05Z

Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

trace2 docs: clarify what `varargs` is all about

2022-05-04T17:31:05Z

Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

trace2 docs: fix a JSON formatted example

2022-05-04T17:31:04Z

The example was not in valid JSON format due to a duplicate key "sid". Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano