Closed idanov closed 2 weeks ago
Quick thought, this will break %load_node immediately. Having a syntax that is identical in "pipelines.py" and DataCatalog is convenient for this case.
Also, what's the size of the parameters here? Can you share a link for the testing project that you used.
I tested with a YAML file ~2MB (100k lines), the nested logic takes less than a second.
It's unclear whether this solution is appropriate and to what extent this PR is ready to be polished by some other team member, could we maybe transform this into an issue and properly prioritize it?
I think we need a broad performance analysis of Kedro to understand where are the main bottlenecks for big projects, see https://github.com/kedro-org/kedro/discussions/3790, https://github.com/kedro-org/kedro-viz/issues/1726
Looks like there was not enough consensus to merge this PR. Left a comment about the underlying user problem at https://github.com/kedro-org/kedro/issues/3893#issuecomment-2203406999
Since there's no consensus on this POC and it's a breaking change, I suggest to close this for now. We have several tickets open regarding performance issues and the DataCatalog
redesign so plenty of opportunities to address this properly in sprint work.
Performance tickets
Catalog redesign
Description
Many users have been complaining about the slowness of Kedro with big projects and that can be attributed to many different causes. However one of the most prevailing cause is big parameter files that get expanded into hundreds of datasets on their own. That process takes a lot of time and if the files become too big (a couple of MB), it presents as significant slowdown.
This Draft PR is a POC in dropping the hack we have built into Kedro to support the convenience syntax of
params:x.y.z
and replacing it with a proper query instead, powered byOmegaConf.select
. This way all datasets which load into a Python dictionary can provide the same functionality out of the box.A side effect is the removal of all those
params:xxxx
datasets from the output ofcatalog.list()
, which is something people have been annoyed by anyways. Nevertheless, it still presents a breaking change, so we need to decide whether it will need a new breaking Kedro version or it can go in as a bugfix/performance fix.This profiling revealed another potential source of slowness and that's the loading of the config files, which is something we should investigate further in the future.
Development notes
Tested with an autogenerated 2.2MB parameters file. As you can see that nearly 2/3 of the time is shaved off.
Before (~120s and 1.17GB memory):
After (~45s and peaked at ~1.10GB memory usage):
Developer Certificate of Origin
We need all contributions to comply with the Developer Certificate of Origin (DCO). All commits must be signed off by including a
Signed-off-by
line in the commit message. See our wiki for guidance.If your PR is blocked due to unsigned commits, then you must follow the instructions under "Rebase the branch" on the GitHub Checks page for your PR. This will retroactively add the sign-off to all unsigned commits and allow the DCO check to pass.
Checklist
RELEASE.md
file