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
Import slowdown after v1 #1127
Comments
(I think the label was added automatically because I selected the 'bug' option when I was opening the issue.) |
See #1124, we can move more things out of Very weird that |
It appears to be caused, in no small part, by the pre-compilation of this particular regex with a range containing 262,057 characters: _domain_ending = r'(?P<tld>\.[a-z]{2,63})?\.?'
_int_chunk = r'[_0-9a-\U00040000](?:[-_0-9a-\U00040000]{0,61}[_0-9a-\U00040000])?'
int_domain_regex = re.compile(fr'(?:{_int_chunk}\.)*?{_int_chunk}{_domain_ending}', re.IGNORECASE) I think the |
Just out of curiosity, I tried to compile it using |
Yes probably, though I doubt you'll get a very helpful response. I think the solution for us is to compile this regex in a lazy way. Eg, only create it when a field using it is used. |
Regexes are compiled and cached on first use by the int_domain_regex = re.compile(fr'(?:{_int_chunk}\.)*?{_int_chunk}{_domain_ending}', re.IGNORECASE) with int_domain_regex = fr'(?i)(?:{_int_chunk}\.)*?{_int_chunk}{_domain_ending}' and then use it like |
I agree, but I think better to explicitly generate and cache, I'll create a PR and let you check. |
thanks for letting me know about tuna, very useful. See #1132 for a fix on most things. We could also move |
The improvement isn't as dramatic for me - it's shaved off about 40ms - but it's definitely noticeable. Thanks for working on this. |
Are you comparing it to current master uncompiled? Could you show me tuna images (or import logs) for before and after #1132? |
Okay, but is v1.3 compiled or simple python? You can check with |
|
Ah right, no, it wasn't compiled. I installed Cython and built 1.3 and #1132 from sdist and it doesn't look it's made much of a difference - still measuring at about 140 ms and 80 ms respectively.
|
Okay weird, I got a bigger difference. |
see my comments on #1132, comment there with any suggestions on how to improve the change, otherwise I'll merge that. |
* improve pydantic import time, fix pydantic#1127, fix pydantic#1039 * more tweaks * tweak utils.py * defering inspect
Co-authored-by: sydney-runkle <sydneymarierunkle@gmail.com> Co-authored-by: Sydney Runkle <54324534+sydney-runkle@users.noreply.github.com> Co-authored-by: Samuel Colvin <s@muelcolvin.com>
After upgrading to v1, I've noticed that it takes almost double the time to import Pydantic. Observe:
v0.32.2 takes approximately 70ms to import on my MBP; v1.3 takes 130ms.
attrs for comparison takes 36ms:
I can understand that this might not be something you'd want to spend time on, depending on what your direction for Pydantic is; but slow warmups have been plaguing Python CLIs for a very long time. If you'd like to investigate this further, tuna can help you visualise your dependency tree. Here's what it's showing me for
tuna (python3 -X importtime -c 'import pydantic' 2>| psub)
:There is the unfortunate practice in Python of importing the entire package's contents in
__init__
and (unfortunately) once you've done that, there's no going back - not without a breaking release anyway.As always, thanks for all your work on Pydantic.
The text was updated successfully, but these errors were encountered: