[Python-Dev] Python startup optimization: script vs. service (original) (raw)

George King gwk.lists at gmail.com
Mon Oct 2 08:05:27 EDT 2017

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>

More information about the Python-Dev mailing list