Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 4, 2017, 21:35 UTC
Message-ID: <xmqqzi6ykwhn.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <20171204203647.30546-1-lars.schneider@autodesk.com>

lars.schneider@autodesk.com writes:

Show 10 quoted lines

> 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.