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 <songofaca...@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 <christ...@python.org > <mailto:christ...@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@python.org <mailto:Python-Dev@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 <songofaca...@gmail.com <mailto:songofaca...@gmail.com>> > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/gwk.lists%40gmail.com
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
