<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 2 Oct 2017 at 02:43 Raymond Hettinger <<a href="mailto:raymond.hettinger@gmail.com">raymond.hettinger@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
> On Oct 2, 2017, at 12:39 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
><br>
> "What requests uses" can identify a useful set of<br>
> avoidable imports. A Flask "Hello world" app could likely provide<br>
> another such sample, as could some example data analysis notebooks).<br>
<br>
Right. It is probably worthwhile to identify which parts of the library are typically imported but are not ever used. And likewise, identify a core set of commonly used tools that are going to be almost unavoidable in sufficiently interesting applications (like using requests to access a REST API, running a micro-webframework, or invoking mercurial).<br>
<br>
Presumably, if any of this is going to make a difference to end users, we need to see if there is any avoidable work that takes a significant fraction of the total time from invocation through the point where the user first sees meaningful output. That would include loading from nonvolatile storage, executing the various imports, and doing the actual application.<br>
<br>
I don't expect to find anything that would help users of Django, Flask, and Bottle since those are typically long-running apps where we value response time more than startup time.<br>
<br>
For scripts using the requests module, there will be some fruit because not everything that is imported is used. However, that may not be significant because scripts using requests tend to be I/O bound. In the timings below, 6% of the running time is used to load and run python.exe, another 16% is used to import requests, and the remaining 78% is devoted to the actual task of running a simple REST API query. It would be interesting to see how much of the 16% could be avoided without major alterations to requests, to urllib3, and to the standard library.<br>
<br>
For mercurial, "hg log" or "hg commit" will likely be instructive about what portion of the imports actually get used. A push or pull will likely be I/O bound so those commands are less informative.<br></blockquote><div><br></div><div>So Mercurial specifically is an odd duck because they already do lazy importing (in fact they are using the lazy loading support from importlib). In terms of all of this discussion of tweaking import to be lazy, I think the best approach would be providing an opt-in solution that CLI tools can turn on ASAP while the default stays eager. That way everyone gets what they want while the stdlib provides a shared solution that's maintained alongside import itself to make sure it functions appropriately.<br></div><div><br></div><div>-Brett<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Raymond<br>
<br>
<br>
--------- Quick timing for a minimal script using the requests module -----------<br>
<br>
$ cat > demo_github_rest_api.py<br>
import requests<br>
info = requests.get('<a href="https://api.github.com/users/raymondh').json(" rel="noreferrer" target="_blank">https://api.github.com/users/raymondh').json(</a>)<br>
print('%(name)s works at %(company)s. Contact at %(email)s' % info)<br>
<br>
$ time python3.6 demo_github_rest_api.py<br>
Raymond Hettinger works at SauceLabs. Contact at None<br>
<br>
real 0m0.561s<br>
user 0m0.134s<br>
sys 0m0.018s<br>
<br>
$ time python3.6 -c "import requests"<br>
<br>
real 0m0.125s<br>
user 0m0.104s<br>
sys 0m0.014s<br>
<br>
$ time python3.6 -c ""<br>
<br>
real 0m0.036s<br>
user 0m0.024s<br>
sys 0m0.005s<br>
<br>
<br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div></div>