[Improvement] progress.track is relatively slow

[kentmartin73]

Description
I really like the look and feel of rich. One thing that stops me using it more is that rich.progress.track is slow compared to tqdm.tqdm

To Reproduce

from rich.progress import track
from time import time
from functools import wraps

import timeit

from tqdm import tqdm

def measure(func):
    """Simple decorator to measure execution time"""
    @wraps(func)
    def _time_it(*args, **kwargs):
        start = int(round(time() * 1000))
        try:
            return func(*args, **kwargs)
        finally:
            end_ = int(round(time() * 1000)) - start
            print(f"Total execution time: {end_ if end_ > 0 else 0} ms")
    return _time_it


@measure
def go_track(count):
    for i in track(range(0, count)):
        pass


@measure
def go_tqdm(count):
    for i in tqdm(range(0, count)):
        pass


count = 1 * 1000 * 1000

print(f"Counting to {count} with rich.progress.track")
go_track(count)
print()
print(f"Counting to {count} with tqdm.tqdm")
go_tqdm(count)

Produces

Counting to 1000000 with rich.progress.track
Working... ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 100% 0:00:00
Total execution time: 3930 ms

Counting to 1000000 with tqdm.tqdm
100%|████████████████████████████| 1000000/1000000 [00:00<00:00, 2808003.77it/s]
Total execution time: 384 ms

Versions etc

   ~  uname -a
Darwin EMB-JBM0HTD5 17.7.0 Darwin Kernel Version 17.7.0: Tue Feb 18 22:51:29 PST 2020; root:xnu-4570.71.73~1/RELEASE_X86_64 x86_64
   ~  python3 --version
Python 3.8.4
   ~  pip3 freeze | grep rich
rich==4.0.0

Thanks!

Kent

[willmcgugan]

Hi Kent,

Interesting. If you set count to 7000 or less then Rich is at least as fast or faster.

I suspect tqdm is monitoring how long things are taking and adapting the rendering accordingly.

Rich progress bars probably are slower, it is generating color codes and its built on a multi-purpose rendering engine. Whereas tqdm has one job.

There's probably a few more optimizations I could make, but frankly its not going to make a difference in a real world task. In your example it takes 3930 milliseconds to do 1 million iterations. That means it will add an overhead of 0.004 milliseconds each iteration, which will likely be a tiny fraction of whatever work is done inside the loop. The difference is only going to be significant if your loop is doing virtually nothing...

[willmcgugan]

Try v4.1.0, it uses a different strategy for very quick iterations. I'm pretty sure tqdm is doing something similar.

[kentmartin73]

Hi, I only just checked this, but they're now about the same speed. Thanks @willmcgugan!