On Thu, Jul 15, 2010 at 2:55 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: >>> In any case, here my results under a Linux system: >>> >>> $ ./python -m importlib.test.benchmark >>> sys.modules [ 323782 326183 326667 ] best is 326667 >>> Built-in module [ 33600 33693 33610 ] best is 33693 >>> >>> $ ./python -m importlib.test.benchmark -b >>> sys.modules [ 1297640 1315366 1292283 ] best is 1315366 >>> Built-in module [ 58180 57708 58057 ] best is 58180 >> >> And this is what might make evaluating importlib tough; while the >> performance is 25% of what it is for import.c, being able to import >> over 300,000 times/second is still damn fast. > > Yeah, I think the numbers where the filesystem gets involved are going > to be more relevant. Modules that have already been cached and those > built in to the executable aren't likely to dominate interpreter and > application startup times (which is the main thing I'm worried about > seeing regress). What about web-applications? Is that true that for FastCgi or mod_wsgi deamon mode interpreter and application is started only once per say 100 requests? -- anatoly t.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4