<div dir="ltr">Hi.<div><br></div><div>My company is using Python for web service.</div><div>So I understand what you're worrying.</div><div>I'm against fine grained, massive lazy loading too.</div><div><br></div><div>But I think we're careful enough for lazy importing.</div><div><br></div><div><a href="https://github.com/python/cpython/pull/3849">https://github.com/python/cpython/pull/3849</a><br></div><div>In this PR, I stop using textwrap entirely, instead of lazy import.</div><div><br></div><div><a href="https://github.com/python/cpython/pull/3796">https://github.com/python/cpython/pull/3796</a><br></div><div>In this PR, lazy loading only happens when uuid1 is used.</div><div>But uuid1 is very uncommon for nowdays.</div><div><br></div><div><a href="https://github.com/python/cpython/pull/3757">https://github.com/python/cpython/pull/3757</a><br></div><div>In this PR, singledispatch is lazy loading types and weakref.</div><div>But singledispatch is used as decorator.</div><div>So if web application uses singledispatch, it's loaded before preforking.</div><div><br></div><div><a href="https://github.com/python/cpython/pull/1269">https://github.com/python/cpython/pull/1269</a><br></div><div>In this PR, there are some lazy imports.</div><div>But the number of lazy imports seems small enough.</div><div><br></div><div>I don't think we're going to too aggressive.<br></div><div><br></div><div>In case of regular expression, we're about starting discussion.</div><div>No real changes are made yet.</div><div><br></div><div>For example, tokenize.py has large regular expressions.</div><div>But most of web application uses only one of them: linecache.py uses</div><div>tokenize.open(), and it uses regular expression for encoding cookie.</div><div>(Note that traceback is using linecache.  It's very commonly imported.)</div><div><br></div><div>So 90% of time and memory for importing tokenize is just a waste not</div><div>only CLI application, but also web applications.</div><div>I have not create PR to lazy importing linecache or tokenize, because</div><div>I'm worrying about "import them at first traceback".</div><div><br></div><div>I feel Go's habit helps in some cases; "A little copying is better than a little dependency."</div><div>(<a href="https://go-proverbs.github.io/">https://go-proverbs.github.io/</a> )</div><div>Maybe, copying `tokenize.open()` into linecache is better than lazy loading tokenize.</div><div><br></div><div><br></div><div>Anyway, I completely agree with you; we should careful enough about lazy (importing | compiling).</div><div><br></div><div>Regards,</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 2, 2017 at 6:47 PM Christian Heimes <<a href="mailto:christian@python.org">christian@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello python-dev,<br>
<br>
it's great to see that so many developers are working on speeding up<br>
Python's startup. The improvements are going to make Python more<br>
suitable for command line scripts. However I'm worried that some<br>
approaches are going to make other use cases slower and less efficient.<br>
I'm talking about downsides of lazy initialization and deferred imports.<br>
<br>
<br>
For short running command line scripts, lazy initialization of regular<br>
expressions and deferred import of rarely used modules can greatly<br>
reduce startup time and reduce memory usage.<br>
<br>
<br>
For long running processes, deferring imports and initialization can be<br>
a huge performance problem. A typical server application should<br>
initialize as much as possible at startup and then signal its partners<br>
that it is ready to serve requests. A deferred import of a module is<br>
going to slow down the first request that happens to require the module.<br>
This is unacceptable for some applications, e.g. Raymond's example of<br>
speed trading.<br>
<br>
It's even worse for forking servers. A forking HTTP server handles each<br>
request in a forked child. Each child process has to compile a lazy<br>
regular expression or important a deferred module over and over.<br>
uWSGI's emperor / vassal mode us a pre-fork model with multiple server<br>
processes to efficiently share memory with copy-on-write semantics. Lazy<br>
imports will make the approach less efficient and slow down forking of<br>
new vassals.<br>
<br>
<br>
TL;DR please refrain from moving imports into functions or implementing<br>
lazy modes, until we have figured out how to satisfy requirements of<br>
both scripts and long running services. We probably need a PEP...<br>
<br>
Christian<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/songofacandy%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/songofacandy%40gmail.com</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Inada Naoki <<a href="mailto:songofacandy@gmail.com">songofacandy@gmail.com</a>></div></div>