On Sat, Aug 19, 2017 at 10:39:41AM -0700, Junio C Hamano wrote:
> We used to expose the full power of the delayed progress API to the
> callers, so that they can specify, not just the message to show and
> expected total amount of work that is used to compute the percentage
> of work performed so far, the percent-threshold parameter P and the
> delay-seconds parameter N. The progress meter starts to show at N
> seconds into the operation only if the amount of work completed
> exceeds P.
> Most callers used either (0%, 2s) or (50%, 1s) as (P, N), but there
> are oddballs that chose more random-looking values like 95%.
> For a smoother workload, (50%, 1s) would allow us to start showing
> the progress meter earlier than (0%, 2s), while keeping the chance
> of not showing progress meter for long running operation the same as
> the latter. For a task that would take 2s or more to complete, it
> is likely that less than half of it would complete within the first
> second, if the workload is smooth. But for a spiky workload whose
> earlier part is easier, such a setting is likely to fail to show the
> progress meter entirely and (0%, 2s) is more appropriate.
> But that is merely a theory. Realistically, it is of dubious value
> to ask each codepath to carefully consider smoothness of their
> workload and specify their own setting by passing two extra
> parameters. Let's simplify the API by dropping both parameters and
> have everybody use (0%, 2s).
Nicely explained (modulo the reversal you noticed in the first
paragraph). The patch looks good to me.
> Oh, by the way, the percent-threshold parameter and the structure
> member were consistently misspelled, which also is now fixed ;-)
Heh, that was bugging me, too. :)
> * So before I forget all about this topic, here is a patch to
>actually do this.
>> So I'd vote to drop that parameter entirely. And if 1 second seems
>> noticeably snappier, then we should probably just move everything to a 1
>> second delay (I don't have a strong feeling either way).
>I was also tempted to do this, but decided to keep it closer to
>the original for majority of callers by leaving the delay at 2s.
>With this patch, such a change as a follow-up is made a lot
>easier (somebody may want to even make a configuration out of it,
>but that would not be me).
Yeah, I agree that it can come later on top (if at all).
Thanks for finishing this off.