Open lurch opened 7 months ago
I sprinkled a load of
new = time.perf_counter(); print(f"Took {new-last}"); last = new
lines throughout the code, and after slightly refactoring this bit:
new = time.perf_counter(); print(f"Took {new-last}"); last = new
richtext = rpipins(options)
new = time.perf_counter();print(f"Took {new-last}"); last = new
rich.print(richtext)
new = time.perf_counter();print(f"Took {new-last}"); last = new
and running python3 -m rpipins --debug --all
, the rpipins()
line takes 0.03 seconds, but the rich.print()
line takes 5.1 seconds. I guess there's probably not a lot you can do about that, so feel free to close this issue if you like.
(The second-largest chunk of time is taken to import
the rich
libraries!)
Hmmm, and I just created a venv and pip-installed the latest version of rich
(13.7.1) to see if it was any faster, but that gives me similar timing figures too.
I wonder if there's any means to fallback from rich to something more traditional for performance concerns. rich really is very, very nice but that loading delay is quite egregious.
I wonder if we can capture and cache its output somehow, since the pinout is mostly static...
I've not done any investigation into where / why it's slowing down, but (testing #11 ) on a Raspberry Pi Model 1 B+ (running over SSH to a headless Pi, rather than a directly-attached monitor and keyboard) ...
time python3 -m rpipins
takes 4 secondstime python3 -m rpipins --all
takes 5 secondstime python3 -m rpipins --debug
takes 6.5 secondstime python3 -m rpipins --debug --all
takes 7 seconds (oof!)I'm not using a virtualenv, I'm using the system-python on the latest Raspberry Pi OS Bookworm 32-bit Lite (with
python3-rich
manually installed).And just to rule out
pinctrl
as being the source of the slowdown,time pinctrl get 0-27
takes just 0.02 seconds :slightly_smiling_face: