what importing this costs, and a budget it has to stay under - #6
Merged
Merged
Conversation
An import is paid at the top of every script, at every kernel restart, and by anyone who typed the name to see whether it is installed, all before anything has been asked of the library. Nothing enforces a budget on that, which is how an import grows five milliseconds a release and nobody notices it getting slow. So the number is checked. A fresh interpreter, the interpreter's own `-X importtime` accounting so that starting the interpreter is not counted against us, five runs because a machine that measures itself is a busy machine, and the fastest and the middle one both have to be under fifty milliseconds. It costs about four here, of which the extension with the engine in it is one and the Python around it is three, most of that `typing`. The Python gets a ceiling of its own, because that is the part that grows a module at a time. The other half of the gate is what is not imported. pandas, polars, pyarrow and numpy are extras rather than dependencies, and importing pandas costs seven hundred milliseconds, which is fourteen times the whole budget. So one test says none of them is in `sys.modules` after `import zudb`, and another says pyarrow arrives exactly when a result is asked for its columns and not one statement earlier.
20 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
import zudbcosts about 4 ms here, and there is now a gate that says it stays under 50.The number is the one from the milestone and the reason for having one at all is that nothing else enforces it. An import is paid at the top of every script, at every kernel restart, and by anyone who typed the name to see whether the thing is installed, all before the library has been asked to do anything. An import that grows five milliseconds a release is an import nobody ever notices getting slow.
What is measured
A fresh interpreter, because that is the only place a cold import happens: once a process has imported a module, importing it again is a dictionary lookup and says nothing about anything. The reading comes from the interpreter's own
-X importtimeaccounting rather than from a clock around the subprocess, which leaves out the cost of starting the interpreter, because that cost is not ours. Five runs, and the fastest and the middle one both have to be inside the budget, so that one busy moment on a CI runner is not a failure and a real regression still is.Where the four milliseconds go, on this machine:
zudbMost of the package's share is
typing, whichzudb.typesneeds for the union that describes a value. The package gets a ceiling of its own at 20 ms, which is a ceiling and not a target: what it catches is a module imported at package scope by somebody who did not need it there, since each one of those costs milliseconds and none of them costs enough to notice on its own.The other half of it
What is not imported. pandas, polars, pyarrow and numpy are extras and not dependencies, and importing pandas costs 700 ms, which is fourteen times the whole budget. One test says none of the four is in
sys.modulesafterimport zudb. Another says pyarrow arrives exactly when a result is asked for its columns and not one statement earlier, which is the property the extras rest on and which nothing else would notice breaking.Both were checked by breaking them: an import of pandas beside the import of zudb makes the first test name all three of pandas, numpy and pyarrow.
202 tests.