-
Notifications
You must be signed in to change notification settings - Fork 909
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[spike] Improve Kedro CLI startup time #1476
Comments
Some older issues about this topic: https://github.com/quantumblacklabs/private-kedro/issues/930 & https://github.com/quantumblacklabs/private-kedro/pull/537 |
I created PR that should solve this problem in kedro-org/kedro-viz#1196 - any help with making tests passed would be appreciated |
(From #3033) Still an issue. For example,
After warmup (i.e. executing the command again immediately after) this can go down to ~1 second. Ahead of this I did some profiling using https://github.com/joerick/pyinstrument and https://www.speedscope.app/, and this is what I found: For |
Some users are puzzled that Today with @rashidakanchwala |
I don't know what happened lately but Kedro has got unacceptably slow. I'm raising the priority of this. |
On my computer, the first time it takes 24 seconds to run As a first step, we may need a better understanding of how slow Kedro CLI startup time is, and why. Some questions I have:
Then as a next step, we'd need an assessment on what can we do about this. Ideally it shouldn't take this long to run seemingly simple commands, even with a cold cache. Can we aim for a combination of slashing the time in ~half + showing something during those initial seconds so the user knows that it didn't get stuck? |
I don't know if the architecture of pluggy or kedro allows this, but if we don't expect plugins to be able to add pipelines to the registry, maybe we should try to delay the plugin discovery process as much as possible. If one runs |
Update re: Lazy Loading of PluginsTLDR: It's possible to lazy load plugins and their commands on Kedro side Prototype PR: #3901 Profile of regular
|
class CommandCollection(click.CommandCollection): |
CommandCollection.list_commands()
, add plugins till it is.Profile of kedro registry list
with lazy loading of plugins
Send telemetry info in after_command_run
[Out of scope]
See: kedro-org/kedro-plugins#709
As mentioned in #1476 (comment), this would not reduce the TOTAL time taken by a command but will reduce the apparent time taken by the command.
Profile of kedro registry list
with lazy loading of plugins + telemetry after_command_run
Profile data
kedro registry list |
regular | with lazy plugin loading | lazy + telemetry after |
---|---|---|---|
initialisation of CLI module | 858ms | 576ms | 553 |
KedroCLI init | 4.11s | 270ms | 287ms |
sending telemetry | 1s | 0.8s | 1s |
time before the main code runs | ~6s | ~1.7s | ~0.8s |
total | 6.96s | 3.76s | 3.8s |
kedro info |
regular | with lazy plugin loading | lazy + telemetry after |
---|---|---|---|
initialisation of CLI module | 860ms | 737ms | 846ms |
KedroCLI init | 3.97s | 292ms | 304ms |
sending telemetry | 1.05s | 880ms | 858ms |
time before the main code runs | ~5.7s | ~1.9s | ~0.8s |
total | 5.99s | 2.03s | 2.12s |
Things to note
- It might take same or more time to run plugin commands - there might be a better way to load only the plugin for which the command we're running than just iterating through the entrypoints till we load the plugin which has the command
- There'll also be some delay when the command is wrong or doesn't exist. For eg
kedro infroo
will take a while before the error message is displayed because we'll spend some time loading plugins. I don't think this is too bad since we eagerly load these commands already right now. - We could still consider combining this with the
LazyGroup
strategy in Refactor CLI with lazy subcommands and deferring imports kedro-viz#1920 and Lazy load click subcommands #3883 or just look into improving the CLI setup onkedro-viz
in general. Kedro viz could be sped up a little bit by delaying imports at least 🤔
I'm amazed |
Yeah in this case it would make sense to make it async, but... pytest-dev/pluggy#320 |
I was just testing the switch to I'll create a separate issue for |
We still have the project hook that send telemetry immediately after. We should combine the two hooks to avoid checking consent twice as well. |
For now, shall we then proceed with ? How does kedro-org/kedro-viz#1920 interact or conflict with #3901 ? |
These solutions can be used together of course,
I think it's definitely worth refactoring CLI code on There's another thing to note - After lazy plugin loading (i.e after #3901), we lose the plugin commands from the top-level help text: But you can always do |
Good point about losing visibility of the full list in |
Are there any contraindications to:
This way, once loaded, the process with libraries would be ready to fork, unless stopped using cli command. |
@znfgnu IPython essentially? |
I think - and correct me if I'm wrong - the suggestion is about creating a long living kedro process and then a client process expose the CLI and can interact with it without the start-up penalty |
Would the user need to do anything differently? If we can make this almost invisible to the users then it's great. Is there any examples of Python base CLI doing this? |
The current notion of Kedro is that it's a library and a framework. I don't think we should underestimate the consequences of making it a service, in terms of software architecture, reusability, perception etc. Feel free to open a new discussion https://github.com/kedro-org/kedro/discussions/ |
Discussed in Tech Design on 19th June: Two approaches discussed:
The drawbacks of second approach:
Decision: To go with approach 1 for now - lazy subcommands on Kedro and Kedro Viz with delayed imports, and make sure that the help texts still show up. |
Dropping this here as a interesting historical reference.
https://peps.python.org/pep-0690/#motivation (rejected) This is just a hard problem in Python in general. |
Any follow-up tasks here @ankatiyar? Should we then encourage plugins to make their CLI groups lazy, do we need any documentation updates, are we going with the |
kedro-org/kedro-plugins#707 Same question as above, are we still planning to move telemetry to |
Thanks, I had lost track of that PR. The other questions stand |
@noklam @astrojuanlu
Both are in current sprints of framework and viz respectively. Not sure about docs, maybe we can add a recommended way to define CLI commands i.e. with |
yes! |
Description
Currently, Kedro CLI startup time can be slow even if very little work is done, for example, doing
kedro
to show the available command or help can take a few seconds. These commands should feel instant since it is just printing out some help text without any heavy work.Useful tool to profile import time
python -X importtime run.py
kedro
command itself takes 0.7s, which isn't fast but still an acceptable response time. Initial investigation suggests that it can take few seconds mainly due to a slow import during plugin registration.Kedro startup time with plugin installed
(0.7s, removed screenshot)
Kedro startup time with no plugin installed (telemetry + viz)
Causes:
kedro
itselfpkg_resource
(something that is run withconsole_script
)Context
Why is this change important to you? How would you use it? How can it benefit other users?
The Kedro CLI can be slow sometimes and lead to a bad user experience. It should be the most common way that users interact with kedro.
Possible Implementation
(Optional) Suggest an idea for implementing the addition or change.
The first improvement that can be done is to do lazy loading in plugin registration to address (1). (2) & (3) will requires more time to study.
Possible Alternatives
(Optional) Describe any alternative solutions or features you've considered.
Compile some of the kedro CLI, so it prints out help message without actually loading any python code.
e.g.
kedro
-> Load some pre-compiled text files and print, it may be tricky with plugins though.The text was updated successfully, but these errors were encountered: