Very slow on a Pi 1

[lurch]

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 seconds
• time python3 -m rpipins --all takes 5 seconds
• time python3 -m rpipins --debug takes 6.5 seconds
• time 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).

$ apt policy python3
python3:
  Installed: 3.11.2-1
  Candidate: 3.11.2-1
  Version table:
 *** 3.11.2-1 500
        500 http://raspbian.raspberrypi.com/raspbian bookworm/main armhf Packages
        100 /var/lib/dpkg/status
$ apt policy python3-rich
python3-rich:
  Installed: 13.3.1-1
  Candidate: 13.3.1-1
  Version table:
 *** 13.3.1-1 500
        500 http://raspbian.raspberrypi.com/raspbian bookworm/main armhf Packages
        100 /var/lib/dpkg/status

And just to rule out pinctrl as being the source of the slowdown, time pinctrl get 0-27 takes just 0.02 seconds 🙂

[lurch]

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!)

[lurch]

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.

[Gadgetoid]

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...