On Tue, May 12 2020, Emily Shaffer wrote:
[Replying to a change long-since merged into git.git's "master"]
> Rather than teaching only one operation, like 'git fetch', how to write
> down throughput to traces, we can learn about a wide range of user
> operations that may seem slow by adding tooling to the progress library
> itself. Operations which display progress are likely to be slow-running
> and the kind of thing we want to monitor for performance anyways. By
> showing object counts and data transfer size, we should be able to
> make some derived measurements to ensure operations are scaling the way
> we expect.
Did you end up using this data for anything?
> [...]
> @@ -320,6 +321,22 @@ void stop_progress(struct progress **p_progress)
> {
> finish_if_sparse(*p_progress);
>
> + if (p_progress && *p_progress) {
> + trace2_data_intmax("progress", the_repository, "total_objects",
> + (*p_progress)->total);
We start progress bars for various things in git, yet the trace2 data
calls every such progress bar with a total "total_objects", even though
we may not be counting anything to do with objects.
Wouldn't simply s/total_objects/total/ make more sense here, do you rely
on the name of the current key?
