[Python-Dev] Python startup optimization: script vs. service

[George King]

I’m new to this issue, but curious: could the long-running server mitigate lazy loading problems simply by explicitly importing the deferred modules, e.g. at the top of __main__.py? It would require some performance tracing or other analysis to figure out what needed to be imported, but this might be a very easy way to win back response times for demanding applications. Conversely, small scripts currently have no recourse.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20171002/05833436/attachment.html>