From: Junio C Hamano <gitster@pobox.com>
To: lars.schneider@autodesk.com
Cc: git@vger.kernel.org, peff@peff.net, nico@cam.org,
Lars Schneider <larsxschneider@gmail.com>
Subject: Re: [PATCH v1] progress: print progress output for all operations taking longer than 2s
Date: Mon, 04 Dec 2017 13:35:00 -0800 [thread overview]
Message-ID: <xmqqzi6ykwhn.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20171204203647.30546-1-lars.schneider@autodesk.com> (lars schneider's message of "Mon, 4 Dec 2017 21:36:47 +0100")
lars.schneider@autodesk.com writes:
> 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.
prev parent reply other threads:[~2017-12-04 21:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-04 20:36 [PATCH v1] progress: print progress output for all operations taking longer than 2s lars.schneider
2017-12-04 21:33 ` Jeff King
2017-12-04 21:38 ` Junio C Hamano
2017-12-04 22:02 ` [PATCH 0/2] fix v2.15 progress regression Jeff King
2017-12-04 22:05 ` [PATCH 1/2] progress: set default delay threshold to 100%, not 0% Jeff King
2017-12-04 22:07 ` [PATCH 2/2] progress: drop delay-threshold code Jeff King
2017-12-05 10:37 ` Lars Schneider
2017-12-05 11:10 ` Ævar Arnfjörð Bjarmason
2017-12-05 12:28 ` Lars Schneider
2017-12-04 22:22 ` [PATCH 0/2] fix v2.15 progress regression Junio C Hamano
2017-12-04 21:35 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqzi6ykwhn.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=lars.schneider@autodesk.com \
--cc=larsxschneider@gmail.com \
--cc=nico@cam.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).