git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] progress: simplify "delayed" progress API

From
Jeff King <peff@peff.net>
Date
Aug 20, 2017, 07:43 UTC
Message-ID
<20170820074318.3fchxwbuux5zbkah@sigill.intra.peff.net>
In-Reply-To
<xmqqy3qf8nj6.fsf_-_@gitster.mtv.corp.google.com>
On Sat, Aug 19, 2017 at 10:39:41AM -0700, Junio C Hamano wrote:
Show 25 quoted lines
> 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. :)
Show 12 quoted lines
>  * 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.
-Peff
Previous: Junio C HamanoNext: Junio C Hamano
Message 32 of 34 in “Add progress to format-patch and rebase”
  1. 0/2 Add progress to format-patch and rebaseKevin Willford, May 31, 2017
  2. 1/2 format-patch: have progress option while generating patchesKevin Willford, May 31, 2017
  3. Stefan BellerMay 31, 2017
  4. Kevin WillfordMay 31, 2017
  5. Jeff KingMay 31, 2017
  6. Junio C HamanoJun 1, 2017
  7. Johannes SchindelinJun 1, 2017
  8. Jeff KingJun 1, 2017
  9. 2/2 rebase: turn on progress option by default for format-patchKevin Willford, May 31, 2017
  10. Stefan BellerMay 31, 2017
  11. Kevin WillfordMay 31, 2017
  12. Stefan BellerMay 31, 2017
  13. Johannes SchindelinJun 1, 2017
  14. Jeff KingMay 31, 2017
  15. Junio C HamanoJun 3, 2017
  16. 0/2 Add progress for format-patch and rebaseKevin Willford, Aug 10, 2017
  17. 2/2 rebase: turn on progress option by default for format-patchKevin Willford, Aug 10, 2017
  18. Junio C HamanoAug 11, 2017
  19. 1/2 format-patch: have progress option while generating patchesKevin Willford, Aug 10, 2017
  20. Jeff KingAug 10, 2017
  21. Junio C HamanoAug 11, 2017
  22. Philip OakleyAug 12, 2017
  23. Jeff KingAug 13, 2017
  24. Junio C HamanoAug 14, 2017
  25. Junio C HamanoAug 14, 2017
  26. Jeff KingAug 14, 2017
  27. Junio C HamanoAug 14, 2017
  28. Jeff KingAug 14, 2017
  29. Junio C HamanoAug 14, 2017
  30. progress: simplify "delayed" progress APIJunio C Hamano, Aug 19, 2017
  31. Junio C HamanoAug 19, 2017
  32. Jeff KingAug 20, 2017
  33. Junio C HamanoAug 10, 2017
  34. Jeff KingAug 10, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.