This patch limits the estimate time interval to roughly the last minute
(configurable by estimateinterval) to be more practical. See the test
change for why this is better.
.. feature:: Estimated time is more accurate with non-linear progress
mbthomas | |
durin42 |
hg-reviewers |
This patch limits the estimate time interval to roughly the last minute
(configurable by estimateinterval) to be more practical. See the test
change for why this is better.
.. feature:: Estimated time is more accurate with non-linear progress
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
mercurial/progress.py | ||
---|---|---|
261–262 | I think this is saying: "if we suddenly start going really slowly (e.g. a stall), don't give wildly high estimates." Is that right? |
Thanks for the patch - the current behavior has bothered me as well and we should improve the time estimation algorithm for reasons you've outlined.
Is there a reason you went with 60s? Have you experimented with shorter values? (Obviously this can be bikeshedded later because it is a config option and easy to change. I'm just curious where magic numbers come from.)
I'm also not sure why progress.estimate is experimental. I think we should remove that label.
mercurial/progress.py | ||
---|---|---|
108 | Do we not have a configfloat()? This is being used in the context of non-integer math, so IMO it should be a float. | |
260 | Nit: maybe just cast something to a float so we can avoid the useless multiply by 1.0? |
Is there a reason you went with 60s? Have you experimented with shorter values? (Obviously this can be bikeshedded later because it is a config option and easy to change. I'm just curious where magic numbers come from.)
Intuitively, shorter values can make things less smooth (xkcd612). That said, 60s was not chosen very scientifically. If it has to come from something, maybe the first interval of uptime. I have that uptime value displayed in my i3-status.
I'm also not sure why progress.estimate is experimental. I think we should remove that label.
That's what I thought too. I'll send a follow-up.
mercurial/progress.py | ||
---|---|---|
108 | Thanks. I wasn't aware configfloat is available. It should be used here. | |
260 | Right. configfloat will solve that. | |
261–262 | Yes. |
Do we not have a configfloat()? This is being used in the context of non-integer math, so IMO it should be a float.