[Yum-devel] [PATCH] Start meters immediately, and only when asked to. BZ 831904, 831291.

[Zdenek Pavlas]

> between .start() and the first .update() which contains data is "dead
> time", and you get misleadingly low N MB/s numbers that have to build
> up to the correct value.

Yes, but this *is* part of the request processing..

If excluded, rate estimator believes that first chunk (16kB, usually)
took 0 ms, and when 2nd chunk arrives, it actually reports 2x the 
real speed.

URLGrabber updates progress meters BOTH from _retrieve() and 
_progress_update() callbacks. _retrieve() compensates for this 
(current buffer length is not included in amount read),
but _progress_update() does not.

>  Using MultiProgress might change all this too.

I've used the same "delayed" start() logic there, too.  But that
IF in .update() path feels ugly, and instead of copy-pasting this
to .end() path too, to fix BZ 831904, I'd rather get rid of it.

The "mirror profiler" uses independent timing, as we need
it to work with meter=None, too :)  It's done in downloader
to elliminate latency of IPC, and stuff like master process
running "checkfunc" callbacks, but I DO include connection setup,
too (trt, IMO).