Replies: 6 comments 10 replies
-
|
Most of typer's startup time (>85%) comes from loading rich modules in
This means that these time-consuming import are not needed "normal" execution flows (no help, no errors). If you're not using rich in your CLI, you can avoid this delay by using My app is using rich, but I would still want to avoid that delay, mainly because of autocompletion. The 400 ms delay after pressing the tab key is quite noticeable. In my own code, I can defer loading rich (and other slow dependencies) until it's actually needed, so that it doesn't slow down autocompletion. However, I cannot avoid the import of Would you be interested in a PR that changes |
Beta Was this translation helpful? Give feedback.
-
|
I'd second this - I also ran into the same thing, where I'd a simple cli app that had annoying latency in the startup time: using Deferring the import unless its actually needed seems like it'd be a good idea (or failing that, some way to flag that I don't want it to be used even if installed) |
Beta Was this translation helpful? Give feedback.
-
|
Different library, but this is something we noticed in
More info: https://ewels.github.io/rich-click/blog/2024/04/30/version-1.8/ |
Beta Was this translation helpful? Give feedback.
-
|
Chiming in with some data. Latency is embarrassing for a CLI tool. Yes, this is mostly a Python problem, not a Typer problem, but it would be nice to improve. There is a long history of lazy-loading PEPs, take a look if you are patient and brave 🤣. Here's my app: import typer
app = typer.Typer()
@app.command()
def main(name: str):
print(f"Hello {name}")My shell reports ~400ms to get any output from this application 🤨 Of course it's the imports. Run: See that typer uses the vast majority of the import time - the cumulative 1,245,672uS: I am working on portable python packaging and distribution 💀 and hacked lazy imports would break the dependency analysis. Which is why there are a bunch of PEPs on the topic. After surveying themm and considering that the WILL to improve this has existed for like 15 years, I am not confident that import performance of python will ever improve. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, removing the rich import cuts time to 200ms which is not too bad. But it looks SO SAD 😢 Weirdly I can't seem to find any discussions over at Rich. |
Beta Was this translation helpful? Give feedback.
-
|
I have a weird result wherein rich.color takes 75ms-95ms to import with this line in rich.color: WINDOWS = platform.system() == "Windows"And ~2ms (after compilation) with WINDOWS = TrueSo that sucks. I get the same performance with WINDOWS = sys.platform == "win32"Because it's a compile time vs runtime. I will upstream to rich. |
Beta Was this translation helpful? Give feedback.
-
|
I've made this fix a few more places in Rich and it's cut the import time of |
Beta Was this translation helpful? Give feedback.
-
|
Please review the upstream changes to Rich here: Textualize/rich#3399 I am seeing a ~100ms improvement of the Rich import, making it about twice as fast. |
Beta Was this translation helpful? Give feedback.
-
|
"on my machine" |
Beta Was this translation helpful? Give feedback.
-
|
After this, I think the next largest gain would be for Typer to avoid importing Markdown by default. Unsure of scope. FYI @tiangolo |
Beta Was this translation helpful? Give feedback.
-
|
So, just wanted to follow up on this discussion since this is something we're now noticing. Out of curiosity, I benchmarked import times for the same typer app @JPHutchins made but with their fixes to rich applied (which are merged but not released) and kept going to see if I could cut things down further in the "fast path" (by that I mean you're just invoking the CLI with no special rich console printing, etc.). Our test app is: We'll start with We see indeed that the So, I tried to make the Turns out it's not quite as simple to get rid of Finally, I noticed in So after applying all these changes: That's a ~35% import speedup on top of @JPHutchins's awesome changes to rich. So compared to currently released Of course, if you actually use rich functionality, etc. you'll pay those import costs. That's fine. The goal here is to cut the import time in the general case wherever possible. Will be submitting a PR if @tiangolo is OK with it. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! Really great data and proof of concept! Re: lazy imports, these may need to be called out as "hidden imports" when people (like me) are packing using pyinstaller or similar tools. The history of lazy import PEPs and forum threads is long and rather deflating. Now they're tied up in static typing problems - because the type system needs to always import to check types, so it seems like new language features are needed: "lazy import my_dependency". Built-in lazy import support is the most reasonable path, but until then I think that manual lazy imports, as long as they are documented, are a good step towards proving that it's the best path. I might even recommend a comment at the top of each file that lazy imports so that the dependencies can be tracked down easily. It's not just typer, or rich - my "real" typer app uses pydantic, which also has really slow startup times, despite "rust", and despite wide adoption. (Startup times really only matter for little tools and CLIs). Also, if you run a Python app that imports nothing and does nothing, it's still pretty slow to start and exit 😢. A big learning from the rich case was that having non constant variables in global scope causes compile-time (and then import time) slowdowns for Python, something I'd never really thought about before. Meanwhile pydantic is over here constructing entire objects at compile/import time - not good! - will be interesting to see what fixes they come up with! JP PS: how do you make these icicle graphs? |
Beta Was this translation helpful? Give feedback.
-
@JPHutchins we need to declare them (lazy imports) anyways in most cases for type checkers. For instance: Type checkers like pyright and linters like ruff work cleanly with this pattern. Some imports (not used in function declarations) don't need to be forward declared like this though and might complain about unused imports if you still put them there (though this can be ignored on a per-line level). In general, I'd advise against trying to determine all dependencies through introspection. This is always best done explicitly in eg; a pyproject.toml/meta.yaml given all the caveats in detecting runtime imports.
I agree that unfortunately the Python community kinda lost its opportunity creating a clean lazy import solution. Even the approach above is rather "ugly" and you need to manually profile to see which imports you want to do. And often times repeat the lazy import many times in a file. The resolution that rejected PEP 690 noted that it would fragment how libraries are authored, etc. But it failed to understand that we find ourselves here regardless... Funny enough PEP 690 was incorporated into Cinder, Meta's Python fork.
We also use Pydantic in a CLI but lazily import it so the latency is only felt when eg; making outbound requests. I understand that this is not always possible though.
Unfortunately interpreter startup time is unfortunately well out of scope of this discussion. At best we can hope it doesn't get measurably worse.
Just used tuna to visualize |
Beta Was this translation helpful? Give feedback.
-
I think that this is good because it's explicit and it creates a good path for pyinstaller support! I'll find out what I'm overlooking the hard way.
I hadn't heard of this, fascinating! It does make sense that static typing should result in better optimization opportunities. Nuitka seems to attempt something like that, though my applications do not run noticeably faster.
I may try, but I may switch to builtin dataclass first since I mostly work with tiny binary protocols and pydantic is a bit overkill! I've worked on my own "python application packager" - like pyinstaller, nuitka, etc. - to understand why they all feel so hack, and from profiling python startup it is hard to see how to improve things and still have a fully compatible build system. |
Beta Was this translation helpful? Give feedback.
-
|
One solution if found especially helpful when dealing with static import analysis (pyinstaller, nuitka) and lazy imports is to leverage ie: from typing import TYPE_CHECKING
from lazyasd import lazyobject
if TYPE_CHECKING:
import rich
else:
@lazyobject
def rich():
import rich
return richDuring type checking / ide autocompletion / static import analysis, At runtime, |
Beta Was this translation helpful? Give feedback.
-
Hey @iamthebot! That's an awesome analysis 🙏 We'd definitely appreciate a PR on this. It's always easier to understand the actual effect on the codebase by looking at concrete PR contributions. If there are straightforward fixes, as well as more convoluted fixes, please consider splitting them into separate PRs. We'd probably be able to review/merge smaller, isolated fixes more easily than considering everything at once. So while multiple PRs may seem like more work / slower progress, it would actually help getting things over the line more quickly 😎 |
Beta Was this translation helpful? Give feedback.
-
First Check
Commit to Help
Example Code
Description
Is there any way to increase performance of using Typer? For example, I could imagine there are some flags one can disable?
I'm running Typer on a Raspberry Pi 3, which is - of course - not as fast as my MacBook.
Stats
$ time python test.py hello real 0m2.071s user 0m1.936s sys 0m0.112sFor my own, larger but not excessive, CLI
$ time python cli.py --help real 0m5.411s user 0m4.656s sys 0m0.301sI saw in other issues I could perhaps make my imports dynamic to shave off some time, but perhaps there are some Typer-related features I can leverage.
Operating System
Linux
Operating System Details
Raspberry Pi 3
Typer Version
0.9.0
Python Version
3.9.2
Additional Context
No response
Beta Was this translation helpful? Give feedback.
All reactions