Closed GoogleCodeExporter closed 9 years ago
I had actually thought about this issue. The only problem is incurring a call
for time.time() in every step. I'll see if that can be avoided (maybe using an
alarm, or a secondary thread), but it might even not be worth it.
Original comment by nilton.v...@gmail.com
on 3 Aug 2010 at 5:13
+1, maybe ETA can be used to determine number of updates required for smooth
operation?
Original comment by kal...@gmail.com
on 14 Dec 2010 at 3:14
I'm not convinced that calling `time.time()` is a large problem
From IPython
In [1]: import time
In [2]: %timeit time.time()
1000000 loops, best of 3: 269 ns per loop
Original comment by Wolphie
on 14 Dec 2010 at 3:28
Interesting. It's a bit slower in the machine I'm using right now:
In [22]: %timeit pbar._need_update()
timeit1000000 loops, best of 3: 617 ns per loop
In [23]: %timeit time.time()
1000000 loops, best of 3: 1.37 µs per loop
Adding a call to time.time() in _need_update() increases the time of a single
call to:
In [54]: %timeit pbar._need_update()
100000 loops, best of 3: 2.31 µs per loop
Original comment by nilton.v...@gmail.com
on 14 Dec 2010 at 10:01
Still doesn't look like a large enough amount to worry about. If you're
actually running updates on the progress bar more than 432,900 times per second
than you've got a different problem ;)
Original comment by Wolphie
on 14 Dec 2010 at 10:08
Done in
https://code.google.com/p/python-progressbar/source/detail?r=a00c6b7ca3c5a1cd7c3
8386e91bffde086607e3d
Please check if it's OK, if you can. Thanks.
Original comment by nilton.v...@gmail.com
on 15 Dec 2010 at 3:30
It's working perfectly. Great patch!
Original comment by Wolphie
on 16 Dec 2010 at 7:01
Original issue reported on code.google.com by
Wolphie
on 1 Aug 2010 at 3:20