Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s
- Date: Mon, 04 Dec 2017 13:35:00 -0800
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s
> In 180a9f2 we implemented a progress API which suppresses the progress
> output if the progress has reached a specified percentage threshold
> within a given time frame. In 8aade10 we simplified the API and set the
> threshold to 0% and the time frame to 2 seconds for all delayed progress
> operations. That means we would only see a progress output if we still
> have 0% progress after 2 seconds. Consequently, only operations that
> have a very slow start would show the progress output at all.
> Remove the threshold entirely and print the progress output for all
> operations that take longer than 2 seconds.
Isn't this likely to result in much chattier progress output (read:
regression) forplaces whose the (P, N) was (0%, 2s) before 8aade107
("progress: simplify "delayed" progress API", 2017-08-19)?
Before or after that change, the places that passed (0%, 2s)
refrained from showing any progress, if at least 1 per-cent of the
work has finished at 2-second mark. With this change, they will
suddenly start showing progress after 2-second mark, even if they
completed that much work already.
The places that did change the behaviour with the cited change are
the ones that used parameters different from (0%, 2s). "git blame",
"diffcore-rename" and "unpack-trees" seem to be among them; they
used (50%, 1s), and we'd have seen the progress meter after 1s,
unless half of the work is already done by that time. By replacing
that with (0%, 2s), the change made it a lot less likely to trigger.
The analysis in the cited commit log claims that (50%, 1s) is
equivalent to (0%, 2s) when the workload is smooth, but I think that
math is bogus X-<.
And the one in prune-packed, which used to be (95%, 2s), is quite
different from the value after the simplification. We deliberately
made it 95 times more unlikely to trigger with that commit---it used
to be that unless 95% of work is already done, we saw progress
starting at 2-second mark, but now we see progress only when less
than 1% of work is done at 2-second mark.