Line.eta is not nice to slow processes.
pveber opened this issue · comments
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.
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.
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!
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.
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.
#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.