Re: [PATCH] trace2: log progress time and throughput
- From
Josh Steadmon <steadmon@google.com>
- Date
- May 13, 2020, 19:46 UTC
- Message-ID
- <20200513194604.GA163566@google.com>
- In-Reply-To
- <20200512214420.36329-1-emilyshaffer@google.com>
On 2020.05.12 14:44, Emily Shaffer wrote:
Show 25 quoted lines
> 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. > > Signed-off-by: Emily Shaffer <emilyshaffer@google.com> > --- > One note: by putting trace collection into the progress library, we end > up with data events which have titles like "Receiving objects" - not > very machine-parseable. An alternative might be to ask for a > machine-readable title in the progress struct, but I didn't think it was > worth the code churn. However, I don't have experience with processing > the trace data after it's been collected, so if this is a bigger problem > than I think, please say so and I'll figure something out. > > CI run here, although it failed on the same error Junio noted today[1]: > https://github.com/nasamuffin/git/runs/668457062 > > - Emily > > [1]: https://lore.kernel.org/git/xmqqtv0kc2q1.fsf@gitster.c.googlers.com
I like Junio's idea of adding an optional machine-readable field in the progress struct, but I don't think it is necessarily a blocker for this change. Everything looks good to me.
Reviewed-by: Josh Steadmon <steadmon@google.com>