Re: [Python-Dev] Python startup time

> On 9 Oct 2018, at 23:02, Gregory Szorc wrote: > > > > While we're here, CPython might want to look into getdirentriesattr() as > a replacement for readdir(). We switched to it in Mercurial several > years ago to make `hg status` operations significantly faster [2]. I'm > not sure if it will

Re: [Python-Dev] Python startup time

Hi, On Tue, 9 Oct 2018 14:02:02 -0700 Gregory Szorc wrote: > > Python 3.7 doesn't exhibit as much of a problem. But it is still there. > A brief audit of the importer code and call stacks confirms it is the > same problem - just less prevalent. Wall time execution of the test > harness from Py

Re: [Python-Dev] Python startup time

On 5/1/2018 8:26 PM, Gregory Szorc wrote: > On 7/19/2017 12:15 PM, Larry Hastings wrote: >> >> >> On 07/19/2017 05:59 AM, Victor Stinner wrote: >>> Mercurial startup time is already 45.8x slower than Git whereas tested >>> Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial >>> d

Re: [Python-Dev] Python startup time

On 14.05.2018 18:26, Chris Barker via Python-Dev wrote: > > > On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez > wrote: > > https://refi64.com/uprocd/ > > > very cool -- but *nix only, of course :-( > > But it seems that there is a demand for this sort of thing

Re: [Python-Dev] Python startup time

On Mon, May 14, 2018 at 12:26:19PM -0400, Chris Barker via Python-Dev wrote: > With regard to forking -- is there another way? I don't have the expertise > to have any idea if this is possible, but: > > start up python > > capture the entire runtime image as a single binary blob. > could that b

Re: [Python-Dev] Python startup time

2018年5月15日(火) 2:17 Antoine Pitrou : > > Le 14/05/2018 à 19:12, INADA Naoki a écrit : > > I'm sorry, the word *will* may be stronger than I thought. > > > > I meant if memory image dumped on disk is used casually, > > it may make easier to make security hole. > > > > For example, if `hg` memory ima

Re: [Python-Dev] Python startup time

Le 14/05/2018 à 19:12, INADA Naoki a écrit : > I'm sorry, the word *will* may be stronger than I thought. > > I meant if memory image dumped on disk is used casually, > it may make easier to make security hole. > > For example, if `hg` memory image is reused, and it can be leaked in some > way,

Re: [Python-Dev] Python startup time

I'm sorry, the word *will* may be stronger than I thought. I meant if memory image dumped on disk is used casually, it may make easier to make security hole. For example, if `hg` memory image is reused, and it can be leaked in some way, hg serve will be hashdos weak. I don't deny that it's usefu

Re: [Python-Dev] Python startup time

On Tue, 15 May 2018 01:33:18 +0900 INADA Naoki wrote: > > It will broke hash randomization. > > See also: https://www.cvedetails.com/cve/CVE-2017-11499/ I don't know why it would. The mechanism of pre-initializing a process which is re-used accross many requests is how most server applications

Re: [Python-Dev] Python startup time

On Mon, May 14, 2018 at 12:33 PM, INADA Naoki wrote: > It will broke hash randomization. > > See also: https://www.cvedetails.com/cve/CVE-2017-11499/ I'm not enough of a security expert to know how much that matters in this case, but I suppose one could do a bit of post-proccessing on the image

Re: [Python-Dev] Python startup time

On Tue, May 15, 2018 at 1:29 AM Chris Barker via Python-Dev < python-dev@python.org> wrote: > On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez wrote: >> https://refi64.com/uprocd/ > very cool -- but *nix only, of course :-( > But it seems that there is a demand for this sort of thing, and a

Re: [Python-Dev] Python startup time

On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez wrote: > https://refi64.com/uprocd/ very cool -- but *nix only, of course :-( But it seems that there is a demand for this sort of thing, and a few major projects are rolling their own. So maybe it makes sense to put something into the standard

Re: [Python-Dev] Python startup time - daemon

On Fri, May 11, 2018 at 11:57 PM, Barry Warsaw wrote: > On May 11, 2018, at 12:23, Guido van Rossum wrote: > > > > Indeed, we have an implementation of this specific to mypy. > > Is there anything in mypy’s implementation that can be generalized into a > library? > Not sure, here's the code: ht

Re: [Python-Dev] Python startup time - daemon

On May 11, 2018, at 12:23, Guido van Rossum wrote: > > Indeed, we have an implementation of this specific to mypy. Is there anything in mypy’s implementation that can be generalized into a library? -Barry signature.asc Description: Message signed with OpenPGP ___

Re: [Python-Dev] Python startup time - daemon

Indeed, we have an implementation of this specific to mypy. On Fri, May 11, 2018 at 11:34 AM, Antoine Pitrou wrote: > > Yes, you don't want this to be a generic utility, rather a helper > library that people can integrate into their command-line applications > to enable such startup caching. > >

Re: [Python-Dev] Python startup time - daemon

Yes, you don't want this to be a generic utility, rather a helper library that people can integrate into their command-line applications to enable such startup caching. Regards Antoine. On Fri, 11 May 2018 17:27:35 +0200 Oleg Broytman wrote: > On Fri, May 11, 2018 at 07:38:05AM -0700, Chris B

Re: [Python-Dev] Python startup time - daemon

On Fri, May 11, 2018 at 07:38:05AM -0700, Chris Barker - NOAA Federal via Python-Dev wrote: > Could one make a little startup utility that, when invoked the first > time, starts up a raw python interpreter, keeps it running somewhere, > and then forks it to run the actual python code. > > Then e

Re: [Python-Dev] Python startup time

https://refi64.com/uprocd/ On May 11, 2018 9:39:28 AM Chris Barker - NOAA Federal via Python-Dev wrote: Inspired by chg: Could one make a little startup utility that, when invoked the first time, starts up a raw python interpreter, keeps it running somewhere, and then forks it to run the

Re: [Python-Dev] Python startup time

Inspired by chg: Could one make a little startup utility that, when invoked the first time, starts up a raw python interpreter, keeps it running somewhere, and then forks it to run the actual python code. Then every invocation after that would make a new fork. I presume forking is a LOT faster th

Re: [Python-Dev] Python startup time

On 2018-05-03, Lukasz Langa wrote: > > On May 2, 2018, at 8:57 PM, INADA Naoki wrote: > > * Add lazy compiling API or flag in `re` module. The pattern is compiled > > when first used. > > How about go the other way and allow compiling at Python > *compile*-time? That would actually make things f

Re: [Python-Dev] Python startup time

FYI, a lot of these ideas were discussed back in September and October of 2017 on this list if you search the subject lines for "startup" e.g. starting here and here: https://mail.python.org/pipermail/python-dev/2017-September/149150.html https://mail.python.org/pipermail/python-dev/2017-October/14

Re: [Python-Dev] Python startup time

On Fri, May 4, 2018 at 10:43 AM, Gregory P. Smith wrote: > I'd also like to see this concept somehow extended to decorators so that the > results of the decoration can be captured in the compiled pyc rather than > requiring execution at import time. I realize that limits what decorators > can do,

Re: [Python-Dev] Python startup time

On Thu, May 3, 2018 at 5:22 PM, Lukasz Langa wrote: > > > On May 2, 2018, at 8:57 PM, INADA Naoki wrote: > > > > Recently, I reported how stdlib slows down `import requests`. > > https://github.com/requests/requests/issues/4315#issuecomment-385584974 > > > > For Python 3.8, my ideas for faster s

Re: [Python-Dev] Python startup time

> On May 2, 2018, at 8:57 PM, INADA Naoki wrote: > > Recently, I reported how stdlib slows down `import requests`. > https://github.com/requests/requests/issues/4315#issuecomment-385584974 > > For Python 3.8, my ideas for faster startup time are: > > * Add lazy compiling API or flag in `re` mo

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018 at 6:55 PM, Nathaniel Smith wrote: > On Wed, May 2, 2018, 09:51 Gregory Szorc wrote: >> >> Correct me if I'm wrong, but aren't there downsides with regards to C >> extension compatibility to not having a shared libpython? Or does all the >> packaging tooling "just work" withou

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018 at 2:13 PM, Barry Warsaw wrote: > Thanks for bringing this topic up again. At $day_job, this is a highly > visible and important topic, since the majority of our command line tools > are written in Python (of varying versions from 2.7 to 3.6). Some of those > tools can take

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, 20:59 INADA Naoki wrote: > Recently, I reported how stdlib slows down `import requests`. > https://github.com/requests/requests/issues/4315#issuecomment-385584974 [...] > * Add faster and simpler http.parser (maybe, based on h11 [1]) and avoid > using email module in http m

Re: [Python-Dev] Python startup time

On Thu, 3 May 2018 at 07:31 Nick Coghlan wrote: > On 3 May 2018 at 15:56, Glenn Linderman wrote: > >> On 5/2/2018 8:56 PM, Gregory Szorc wrote: >> >> Nobody in the project is seriously talking about a complete rewrite in >> Rust. Contributors to the project have varying opinions on how aggressiv

Re: [Python-Dev] Python startup time

On 3 May 2018 at 15:56, Glenn Linderman wrote: > On 5/2/2018 8:56 PM, Gregory Szorc wrote: > > Nobody in the project is seriously talking about a complete rewrite in > Rust. Contributors to the project have varying opinions on how aggressively > Rust should be utilized. People who contribute to t

Re: [Python-Dev] Python startup time

I'm hardly an expert, but AFAIK CPython's start-up issues are more due to a mix of architectural issues and the fact that it's hard to optimize imports while maintaining backwards compatibility with Python's dynamism. -- Ryan (ライアン) Yoko Shimomura, ryo (supercell/EGOIST), Hiroyuki Sawano >> eve

Re: [Python-Dev] Python startup time

On 5/2/2018 8:56 PM, Gregory Szorc wrote: Nobody in the project is seriously talking about a complete rewrite in Rust. Contributors to the project have varying opinions on how aggressively Rust should be utilized. People who contribute to the C code, low-level primitives (like storage, deltas,

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018 at 8:26 PM, Benjamin Peterson wrote: > > > On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > > The direction Mercurial is going in is that `hg` will likely become a > Rust > > binary (instead of a #!python script) that will use an embedded Python > > interpreter. So we wil

Re: [Python-Dev] Python startup time

On 5/2/2018 12:42 PM, Gregory Szorc wrote: I know this kinda/sorta exists with zipimporter. But zipimporter uses zlib (slow) and only allows .py/.pyc files. And I think some Python application distribution tools have also solved this problem. I'd *really* like to see a proper/robust solution i

Re: [Python-Dev] Python startup time

Recently, I reported how stdlib slows down `import requests`. https://github.com/requests/requests/issues/4315#issuecomment-385584974 For Python 3.8, my ideas for faster startup time are: * Add lazy compiling API or flag in `re` module. The pattern is compiled when first used. * Add IntEnum and

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, at 09:42, Gregory Szorc wrote: > The direction Mercurial is going in is that `hg` will likely become a Rust > binary (instead of a #!python script) that will use an embedded Python > interpreter. So we will have low-level control over the interpreter via the > C API. I'd also

Re: [Python-Dev] Python startup time

On May 2, 2018, at 15:24, Gregory Szorc wrote: > > FWIW, Google has a patched glibc that implements dlopen_with_offset(). > It allows you to do things like memory map the current binary and then > dlopen() a shared library embedded in an ELF section. > > I've seen the code in the branch at > htt

Re: [Python-Dev] Python startup time

On 5/2/18 2:24 PM, Barry Warsaw wrote: > On May 2, 2018, at 09:42, Gregory Szorc wrote: > >> As for things Python could do to make things better, one idea is for >> "package bundles." Instead of using .py, .pyc, .so, etc files as separate >> files on the filesystem, allow Python packages to be

Re: [Python-Dev] Python startup time

On May 2, 2018, at 09:42, Gregory Szorc wrote: > As for things Python could do to make things better, one idea is for "package > bundles." Instead of using .py, .pyc, .so, etc files as separate files on the > filesystem, allow Python packages to be distributed as standalone "archive" > files.

Re: [Python-Dev] Python startup time

Thanks for bringing this topic up again. At $day_job, this is a highly visible and important topic, since the majority of our command line tools are written in Python (of varying versions from 2.7 to 3.6). Some of those tools can take upwards of 5 seconds or more just to respond to —help, whic

Re: [Python-Dev] Python startup time

Antoine: > The overhead of importing is not in trying too many names, but in > loading the module and executing its bytecode. That was my conclusion as well when I did some profiling last fall at the Python core sprint. My lazy execution experiments are an attempt to solve this: https://gith

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, 09:51 Gregory Szorc wrote: > Correct me if I'm wrong, but aren't there downsides with regards to C > extension compatibility to not having a shared libpython? Or does all the > packaging tooling "just work" without a libpython? (It's possible I have my > wires crossed up with

Re: [Python-Dev] Python startup time

On Tue, May 1, 2018 at 11:55 PM, Ray Donnelly wrote: > Is your Python interpreter statically linked? The Python 3 ones from the anaconda distribution (use Miniconda!) are for Linux and macOS and that roughly halved our startup times. My Python interpreters use a shared library. I'll definitely

Re: [Python-Dev] Python startup time

On Wed, 2 May 2018 11:26:35 +0200 Victor Stinner wrote: > > Brett Cannon is also working on a standard solution for lazy imports > since many years: > https://pypi.org/project/modutil/ > https://snarky.ca/lazy-importing-in-python-3-7/ AFAIK, Mercurial already has its own lazy importer. > Nick C

Re: [Python-Dev] Python startup time

What do you propose to make Python startup faster? As I wrote in my previous emails, many Python core developers care of the startup time and we are working on making it faster. INADA Naoki added -X importtime to identify slow imports and understand where Python spent its startup time. Recent ex

Re: [Python-Dev] Python startup time

On Wed, May 2, 2018, 4:53 AM Gregory Szorc wrote: > On 7/19/2017 12:15 PM, Larry Hastings wrote: > > > > > > On 07/19/2017 05:59 AM, Victor Stinner wrote: > >> Mercurial startup time is already 45.8x slower than Git whereas tested > >> Mercurial runs on Python 2.7.12. Now try to sell Python 3 to

Re: [Python-Dev] Python startup time

On 7/19/2017 12:15 PM, Larry Hastings wrote: > > > On 07/19/2017 05:59 AM, Victor Stinner wrote: >> Mercurial startup time is already 45.8x slower than Git whereas tested >> Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial >> developers, with a startup time 2x - 3x slower...

Re: [Python-Dev] Python startup time

On 23 July 2017 at 09:35, Steve Dower wrote: > Yes, I’m aware of that, which is why I don’t have any specific suggestions > off-hand. But given the differences in file systems between Windows and > other OSs, it wouldn’t surprise me if there were a more optimal approach for > NTFS to amortize call

Re: [Python-Dev] Python startup time

On Sun, Jul 23, 2017, 10:52 Michel Desmoulin, wrote: > > > Le 23/07/2017 à 19:36, Brett Cannon a écrit : > > > > > > On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, > > wrote: > > > > > > > > > Optimizing startup time is incredibly valuable, > > > > I've b

Re: [Python-Dev] Python startup time

Le 23/07/2017 à 19:36, Brett Cannon a écrit : > > > On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, > wrote: > > > > > Optimizing startup time is incredibly valuable, > > I've been reading that from the beginning of this thread but I've been > us

Re: [Python-Dev] Python startup time

On Sun, Jul 23, 2017, 00:53 Michel Desmoulin, wrote: > > > > Optimizing startup time is incredibly valuable, > > I've been reading that from the beginning of this thread but I've been > using python since the 2.4 and I never felt the burden of the startup time. > > I'm guessing a lot of people ar

Re: [Python-Dev] Python startup time

On Sat, 22 Jul 2017 16:35:31 -0700 Steve Dower wrote: > > Yes, I’m aware of that, which is why I don’t have any specific suggestions > off-hand. But given the differences in file systems between Windows and other > OSs, it wouldn’t surprise me if there were a more optimal approach for NTFS > t

Re: [Python-Dev] Python startup time

> Optimizing startup time is incredibly valuable, I've been reading that from the beginning of this thread but I've been using python since the 2.4 and I never felt the burden of the startup time. I'm guessing a lot of people are like me, they just don't express them self because "better start

Re: [Python-Dev] Python startup time

Cc: Python-Dev Subject: Re: [Python-Dev] Python startup time On Sat, Jul 22, 2017, 07:22 Steve Dower, wrote: I believe the trend is due to language like Python and Node.js, most of which aggressively discourage threading (more from the broader community than the core languages, but I see a lot

Re: [Python-Dev] Python startup time

breaking abstractions or designing new APIs. -brett > > Cheers, > > Steve > > > > Top-posted from my Windows phone > > > > *From: *Alex Walters > *Sent: *Saturday, July 22, 2017 1:39 > *Cc: *'Python-Dev' > > > *Subject: *Re: [Python-Dev

Re: [Python-Dev] Python startup time

, Steve Top-posted from my Windows phone From: Alex Walters Sent: Saturday, July 22, 2017 1:39 Cc: 'Python-Dev' Subject: Re: [Python-Dev] Python startup time > -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On B

Re: [Python-Dev] Python startup time

> -Original Message- > From: Python-Dev [mailto:python-dev-bounces+tritium- > list=sdamon@python.org] On Behalf Of Paul Moore > Sent: Saturday, July 22, 2017 4:14 AM > To: David Mertz > Cc: Barry Warsaw ; Python-Dev d...@python.org> > Subject: Re: [Python-

Re: [Python-Dev] Python startup time

On 21 July 2017 at 23:53, David Mertz wrote: > I would guess that Windows users don't tend to run lots of command line > tools where startup time dominates, as *nix users do. Well, in the sense that many Windows users don't use the command line at all, this is true. However, startup time is a def

Re: [Python-Dev] Python startup time

I would guess that Windows users don't tend to run lots of command line tools where startup time dominates, as *nix users do. On Fri, Jul 21, 2017 at 3:21 PM, Barry Warsaw wrote: > On Jul 21, 2017, at 01:25 PM, Nikolaus Rath wrote: > > >That is what Emacs does, and it causes them a lot of troubl

Re: [Python-Dev] Python startup time

Emacs has been unexec'ing for as long as I can remember (which is longer than I can remember Python :). I know that it's been problematic and there have been many efforts over the years to replace it, but I think it's been a fairly successful technique in practice, at least on platforms that suppo

Re: [Python-Dev] Python startup time

On Jul 21, 2017, at 01:25 PM, Nikolaus Rath wrote: >That is what Emacs does, and it causes them a lot of trouble. They're >trying to move away from it at the moment, but the direction is not yet >clear. The keyword is "unexec", and it wrecks havoc with malloc. Emacs has been unexec'ing for as lon

Re: [Python-Dev] Python startup time

On Jul 21 2017, David Mertz wrote: > How implausible is it to write out the actual memory image of a loaded > Python process? That is what Emacs does, and it causes them a lot of trouble. They're trying to move away from it at the moment, but the direction is not yet clear. The keyword is "unexec

Re: [Python-Dev] Python startup time

On Fri, Jul 21, 2017 at 4:12 PM, David Mertz wrote: > How implausible is it to write out the actual memory image of a loaded > Python process? I.e. on a specific machine, OS, Python version, etc? This > can only be overhead initially, of course, but on subsequent runs it's just > one memory map, w

Re: [Python-Dev] Python startup time

On Fri, 21 Jul 2017 00:12:20 -0700 David Mertz wrote: > How implausible is it to write out the actual memory image of a loaded > Python process? I.e. on a specific machine, OS, Python version, etc? This > can only be overhead initially, of course, but on subsequent runs it's just > one memory map,

Re: [Python-Dev] Python startup time

How implausible is it to write out the actual memory image of a loaded Python process? I.e. on a specific machine, OS, Python version, etc? This can only be overhead initially, of course, but on subsequent runs it's just one memory map, which the cheapest possible operation. E.g. $ python3.7 --wr

Re: [Python-Dev] Python startup time

On 21 July 2017 at 15:30, Cesare Di Mauro wrote: > > > 2017-07-21 4:52 GMT+02:00 Nick Coghlan : > >> On 21 July 2017 at 12:44, Nick Coghlan wrote: >> > We can separately measure the cost of unmarshalling the code object: >> > >> > $ python3 -m perf timeit -s "import typing; from marshal import l

Re: [Python-Dev] Python startup time

2017-07-21 4:52 GMT+02:00 Nick Coghlan : > On 21 July 2017 at 12:44, Nick Coghlan wrote: > > We can separately measure the cost of unmarshalling the code object: > > > > $ python3 -m perf timeit -s "import typing; from marshal import loads; > from > > importlib.util import cache_from_source; cach

Re: [Python-Dev] Python startup time

On 21 July 2017 at 12:44, Nick Coghlan wrote: > We can separately measure the cost of unmarshalling the code object: > > $ python3 -m perf timeit -s "import typing; from marshal import loads; from > importlib.util import cache_from_source; cache = > cache_from_source(typing.__file__); data = open(

Re: [Python-Dev] Python startup time

On 21 July 2017 at 05:38, Cesare Di Mauro wrote: > > > 2017-07-20 19:23 GMT+02:00 Victor Stinner : > >> 2017-07-20 19:09 GMT+02:00 Cesare Di Mauro : >> > I assume that Python loads compiled (.pyc and/or .pyo) from the stdlib. >> That's something that also influences the startup time (compiling so

Re: [Python-Dev] Python startup time

2017-07-20 19:23 GMT+02:00 Victor Stinner : > 2017-07-20 19:09 GMT+02:00 Cesare Di Mauro : > > I assume that Python loads compiled (.pyc and/or .pyo) from the stdlib. > That's something that also influences the startup time (compiling source vs > loading pre-compiled modules). > > My benchmark was

Re: [Python-Dev] Python startup time

2017-07-20 19:09 GMT+02:00 Cesare Di Mauro : > I assume that Python loads compiled (.pyc and/or .pyo) from the stdlib. > That's something that also influences the startup time (compiling source vs > loading pre-compiled modules). My benchmark was "python3 -m perf command -- python3 -c pass": I d

Re: [Python-Dev] Python startup time

2017-07-19 16:26 GMT+02:00 Victor Stinner : > 2017-07-19 15:22 GMT+02:00 Oleg Broytman : > > On Wed, Jul 19, 2017 at 02:59:52PM +0200, Victor Stinner < > victor.stin...@gmail.com> wrote: > >> "Python is very slow to start on Windows 7" > >> https://stackoverflow.com/questions/29997274/python-is- >

Re: [Python-Dev] Python startup time

On 20 July 2017 at 23:32, Stefan Behnel wrote: > So, before considering to write an accelerator module in C that replaces > some existing Python module, and thus duplicating its entire source code > with highly increased complexity, I'd like to remind you that simply > compiling the Python module

Re: [Python-Dev] Python startup time

Ivan Levkivskyi schrieb am 20.07.2017 um 13:24: > I agree the start-up time is important. There is something that is related. > ABCMeta is currently implemented in Python. > This makes it slow, creation of an ABC is 2x slower than creation of a > normal class. > However, ABCs are used by many mediu

Re: [Python-Dev] Python startup time

On Thu, 20 Jul 2017 21:29:18 +0900 INADA Naoki wrote: > > WeakSet should be cared specially. > Maybe, ABCMeta can be optimized first. > > Currently, ABCMeta use three WeakSets. But it can be delayed until > `register` or > `issubclass` is called. > So even if WeakSet is implemented in Python, I

Re: [Python-Dev] Python startup time

Hi, Ivan. First of all, Yes, please do it! On Thu, Jul 20, 2017 at 8:24 PM, Ivan Levkivskyi wrote: > I agree the start-up time is important. There is something that is related. > ABCMeta is currently implemented in Python. > This makes it slow, creation of an ABC is 2x slower than creation of a

Re: [Python-Dev] Python startup time

I agree the start-up time is important. There is something that is related. ABCMeta is currently implemented in Python. This makes it slow, creation of an ABC is 2x slower than creation of a normal class. However, ABCs are used by many medium and large size projects. Also, both abc and _collections

Re: [Python-Dev] Python startup time

Hi, I applied the patch above to count the number of times that Python is run. Running the Python test suite with "./python -m test -j0 -rW" runs Python 2,256 times. Honestly, I expected more. I'm running tests with Python compiled in debug mode. And in debug mode, Python startup time is much wor

Re: [Python-Dev] Python startup time

On 7/19/2017 10:05 AM, Nick Coghlan wrote: P.S. I'll also note that we're not *actually* limited to resolving such conflicts in public venues (even though I think that's a good default habit for us to retain): as long as we report the outcome of any mutual agreements about design priorities back

Re: [Python-Dev] Python startup time

: On 19 July 2017 at 21:19, Steven D'Aprano wrote: > But the premise is wrong too. Those hypothetical people don't turn their > Macs on in sequence, each person turning their computer on only after > the previous person's Mac had finished booting. They effectively boot > them up in parallel but o

Re: [Python-Dev] Python startup time

On Wed, Jul 19, 2017 at 04:11:24PM -0700, Chris Barker wrote: > As long as we are talking anecdotes: > > If it could save a person’s life, could you find a way to save ten seconds > off the boot time? If there were five million people using the Mac, and it > took ten seconds extra to turn it on ev

Re: [Python-Dev] Python startup time

As long as we are talking anecdotes: If it could save a person’s life, could you find a way to save ten seconds off the boot time? If there were five million people using the Mac, and it took ten seconds extra to turn it on every day, that added up to three hundred million or so hours per year peo

Re: [Python-Dev] Python startup time

On Wed, 19 Jul 2017 15:26:47 -0400 Ben Hoyt wrote: > Yes, agreed that startup time matters for scripting. I was talking to > someone on the Google Cloud SDK (CLI) team recently, and they said startup > time is a big deal for them ... it's especially problematic for shell tab > completion helpers,

Re: [Python-Dev] Python startup time

Yes, agreed that startup time matters for scripting. I was talking to someone on the Google Cloud SDK (CLI) team recently, and they said startup time is a big deal for them ... it's especially problematic for shell tab completion helpers, because every time you press tab the shell has to load your

Re: [Python-Dev] Python startup time

On 07/19/2017 05:59 AM, Victor Stinner wrote: Mercurial startup time is already 45.8x slower than Git whereas tested Mercurial runs on Python 2.7.12. Now try to sell Python 3 to Mercurial developers, with a startup time 2x - 3x slower... When Matt Mackall spoke at the Python Language Summit s

Re: [Python-Dev] Python startup time

2017-07-19 15:22 GMT+02:00 Oleg Broytman : > On Wed, Jul 19, 2017 at 02:59:52PM +0200, Victor Stinner > wrote: >> "Python is very slow to start on Windows 7" >> https://stackoverflow.com/questions/29997274/python-is-very-slow-to-start-on-windows-7 > >However hard you are going to optimize Pyt

Re: [Python-Dev] Python startup time

On 19 July 2017 at 22:59, Victor Stinner wrote: > == CPython core developers don't care? no, they do care == > > Christian Heimes, Naoki INADA, Serhiy Storchaka, Yury Selivanov, me > (Victor Stinner) and other core developers made multiple changes last > years to reduce the number of imports at st

Re: [Python-Dev] Python startup time

On Wed, Jul 19, 2017 at 02:59:52PM +0200, Victor Stinner wrote: > "Python is very slow to start on Windows 7" > https://stackoverflow.com/questions/29997274/python-is-very-slow-to-start-on-windows-7 However hard you are going to optimize Python you cannot fix those "defenders", "guards" and "

[Python-Dev] Python startup time

Hi, On Twitter, Raymond Hettinger wrote: "The decision making process on Python-dev is an anti-pattern, governed by anecdotal data and ambiguity over what problem is solved." https://twitter.com/raymondh/status/887069454693158912 About "anecdotal data", I would like to discuss the Python st

Re: [Python-Dev] Python startup time

On Thu, Oct 10, 2013 at 4:18 AM, Christian Heimes wrote: > We don't have to use a custom module type to get rid of these imports > (but I like to get my hands a piece of chocolate cake *g*). We can > either implement yet another mutable mapping class for the os module. > That would remove the depe

Re: [Python-Dev] Python startup time

On Thu, Oct 10, 2013 at 9:38 AM, Antoine Pitrou wrote: > Le Thu, 10 Oct 2013 14:36:26 +0200, > Dirkjan Ochtman a écrit : > > > On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes > > wrote: > > > Benchmark of 1000 times "python -c ''" > > > > > > Python 3.4dev with all my experimental patches: >

Re: [Python-Dev] Python startup time

10.10.13 15:25, Christian Heimes написав(ла): Benchmark of 1000 times "python -c ''" What about "python -S -c ''"? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.pytho

Re: [Python-Dev] Python startup time

Le Thu, 10 Oct 2013 10:26:25 -0400, Benjamin Peterson a écrit : > 2013/10/9 Antoine Pitrou : > > Le Wed, 9 Oct 2013 10:29:30 +0200, > > Antoine Pitrou a écrit : > >> Le Tue, 8 Oct 2013 15:43:40 -0400, > >> Benjamin Peterson a écrit : > >> > >> > 2013/10/8 R. David Murray : > >> > > In this conte

Re: [Python-Dev] Python startup time

2013/10/9 Antoine Pitrou : > Le Wed, 9 Oct 2013 10:29:30 +0200, > Antoine Pitrou a écrit : >> Le Tue, 8 Oct 2013 15:43:40 -0400, >> Benjamin Peterson a écrit : >> >> > 2013/10/8 R. David Murray : >> > > In this context, if we'd been *really* smart-lazy in CPython >> > > development, we'd have kep

Re: [Python-Dev] Python startup time

Hi, In an old issue, I proposed a change to not load the sysconfig module when it's not needed. Nobody reviewed the patch, the issue was closed. http://bugs.python.org/issue14057 When -s or -I option is used, we may skip completly the sysconfig module. (It's already the case when -S is used.) B

Re: [Python-Dev] Python startup time

Le Thu, 10 Oct 2013 14:36:26 +0200, Dirkjan Ochtman a écrit : > On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes > wrote: > > Benchmark of 1000 times "python -c ''" > > > > Python 3.4dev with all my experimental patches: > > > > Avg: 0.705161 -> 0.443613: 1.59x faster > > > > 2.7 -> 3.4dev: >

Re: [Python-Dev] Python startup time

On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes wrote: > Benchmark of 1000 times "python -c ''" > > Python 3.4dev with all my experimental patches: > > Avg: 0.705161 -> 0.443613: 1.59x faster > > 2.7 -> 3.4dev: > > Avg: 0.316177 -> 0.669330: 2.12x slower > > 2.7 -> 3.4dev with all my patches

Re: [Python-Dev] Python startup time

Am 10.10.2013 06:41, schrieb yoav glazner: > I'm not sure Droping imports is the best way to go, since every python > script/app will import common modules right on the start and it will > still seem like the interpeter boot is slow. > > making modules load faster seems like a better approch Not

Re: [Python-Dev] Python startup time

On Thu, 10 Oct 2013 07:41:19 +0300, yoav glazner wrote: > I'm not sure Droping imports is the best way to go, since every python > script/app will import common modules right on the start and it will still > seem like the interpeter boot is slow. > > making modules load faster seems like a better

Re: [Python-Dev] Python startup time

Am 10.10.2013 02:18, schrieb Eric Snow: > On Wed, Oct 9, 2013 at 8:30 AM, Christian Heimes > wrote: >> The os module imports MutableMapping from collections.abc. That >> import adds collections, collections.abc and eight more modules. >> I'm not sure if we can do anything about it, though. > > We

Re: [Python-Dev] Python startup time

I'm not sure Droping imports is the best way to go, since every python script/app will import common modules right on the start and it will still seem like the interpeter boot is slow. making modules load faster seems like a better approch On Thu, Oct 10, 2013 at 3:18 AM, Eric Snow wrote: > O

  1   2   >