Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line.eta is not nice to slow processes. #23

Open
pveber opened this issue Nov 19, 2021 · 6 comments
Open

Line.eta is not nice to slow processes. #23

pveber opened this issue Nov 19, 2021 · 6 comments

Comments

@pveber
Copy link

pveber commented Nov 19, 2021

First, thanks for this awesome library! I'm trying to use Line.eta but I always get a --:-- display. I figured out that in my case the event rate is less than 1. This is a problem because this rate seems to be represented by an integer (see the variable per_second).

More generally I don't really understand why Flow_meter.per_second doesn't return a float, since it basically computes a sample estimate of a rate.

@craigfe
Copy link
Owner

craigfe commented Nov 21, 2021

Thanks for the report!

This seems like just an oversight from me. Generally, Flow_meter tries to keep intermediate computation as integers to avoid loss of precision (& unnecessary allocations), but rounding to per_second is clearly a step too far :-) Perhaps we can get away with using e.g. per_microsecond, or just switch to floats and be careful about precision loss.

I'll try to look at this shortly, but time is against me at the moment.

@pveber
Copy link
Author

pveber commented Nov 22, 2021

Thanks for your answer! I'm not sure I get your point about precision: it seems a Flow_meter.t keeps an array of all last n values that were recorded, along with the corresponding timestamps. So computing the rate by summing and dividing by the total time interval as a float should be plenty accurate. It is true that rounding errors accumulate when you performs lots of operations that involve numbers several orders of magnitude apart, but it doesn't seem to me that we are in that kind of situation here.
Also no worries if you don't have time to get back to this soon, thanks again for the early feedback!

@mbarbin
Copy link
Contributor

mbarbin commented Mar 6, 2022

Hi! I noticed this as well, thanks for the discussion, that was helpful! I tried @pveber 's proposed change in a PR, it seemed to do the trick. As far as I can tell, this does not add new allocation and removes some Integer.t -> float steps.

@dinosaure
Copy link
Collaborator

this does not add new allocation and removes some Integer.t -> float steps.

Actually, float is currently boxed, unlike Integer.t. The change incorporated in #27 may have an impact on performance due to the allocations caused by the use of float. As far as I'm concerned, I'm less fussy on this point. However, I'm going to leave this issue open in order to bear in mind that the first proposal may not be the most optimal for everyone.

@dinosaure
Copy link
Collaborator

#27 is merger now but I will keep this issue open and see if we observe some performance regressions due to the usage of a float.

dinosaure added a commit to dinosaure/opam-repository that referenced this issue May 20, 2024
CHANGES:

- Revert the `terminal` API and keep an "happy" path to get size of a tty
  and be compatible with MirageOS (@art-w, @msprotz, craigfe/progress#42, craigfe/progress#43)
- Use a `float` instead of a `int` in `flow_meter per-second` (@mbarbin, craigfe/progress#23, craigfe/progress#27)
@pveber
Copy link
Author

pveber commented Aug 18, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants