⚡️ Lazy-load rich_utils to reduce startup time

[oefe]

Lazy-load rich_utils (and rich.traceback) to reduce import time.

Fixes #744

There was some discussion in that issue about using lazyasd and if TYPE_CHECKING: in order to make the import known to type checkers and build tools that perform import analysis.

To keep it simple, I didn't go that route.
There are already a few lazy imports, so I think this doesn't change the big picture.
And lazyasd appears to be no longer maintained.

Let me know if you rather would use lazyasd and/or if TYPE_CHECKING:.

Benefit

This cuts down startup overhead by 45%. Below are some measurements (best of 5 runs).
Measured on a Mac mini (M4 pro).

Before

~/R/typer►time uv run docs_src/first_steps/tutorial001.py
Hello World

________________________________________________________
Executed in   94.19 millis    fish           external
   usr time   71.72 millis    0.15 millis   71.57 millis
   sys time   19.54 millis    1.76 millis   17.77 millis

After

~/R/typer►time uv run docs_src/first_steps/tutorial001.py
Hello World

________________________________________________________
Executed in   51.99 millis    fish           external
   usr time   37.36 millis    0.10 millis   37.26 millis
   sys time   12.77 millis    1.37 millis   11.39 millis

[bonastreyair]

I am also looking forward for this quick win, CLI should be faster than it is right now...

[N-Demir]

+1

[stinovlas]

Looks good to me (I'm not a maintainer though).

I did follow the review process, downloaded and ran the code. Everything seems to be fine. This PR doesn't add any tests and I think that's OK, because the code is already tested and it's not changing behavior, it's just a performance optimization.

[oefe]

Originally, I thought the same. While the speedup is significant, it would be difficult to test reliably in a unit test, and I didn't want to introduce a flaky test.

But thinking about it again, I realize that it would be possible to assert that rich is not imported. This is deterministic and should be testable.

[oefe]

OK, added a test

[svlandeg]

Thanks for the clear analysis and PR proposal @oefe!

I can definitely see the appeal of doing the lazy load to improve startup time when rich isn't used. It clutters the code a little bit, but the trade-off may be worth it.

One question I have is for when you do have Rich installed. Do the multiple import statements at different points in the code base result in an efficiency loss somehow? Because I can imagine that in the background, it is being checked what is already imported and what isn't. I'm not sure if that check leaves a performance trace or not.

[svlandeg]

This is a matter of personal preference, but for clarity of code I would prefer

Suggested change

	assert not modules
	assert len(modules) == 0

[oefe]

This is arguably the most idiomatic style, see also PEP8:

For sequences, (strings, lists, tuples), use the fact that empty sequences are false:

# Correct:
if not seq:
if seq:
# Wrong:
if len(seq):
if not len(seq):

But I can change it if you prefer.

[svlandeg]

I'll leave the final decision with Tiangolo 🙏

[oefe]

The performance impact is negligible. Essentially, it boils down to one dictionary lookup (to test whether the module is already in says.modules) and one dictionary insertion (add the module to the local namespace). These are both very quick.

Also, most of the affected lines are executed at most once per run.

[svlandeg]

The performance impact is negligible.

Thanks for double checking!

This PR looks good to merge to me, I'll leave it to Tiangolo for a final review.