Re: Improving interpreter startup speed

BJörn Lindqvist wrote: > 2008/10/27 James Mills <[EMAIL PROTECTED]>: >> On Mon, Oct 27, 2008 at 5:40 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: >>> Depends on the tool: build tool and source control tools are example >>> it matters (specially when you start interfaciing them with IDE or >>> ed

Re: Improving interpreter startup speed

Tried using the precache daemon to see if it gives any boost? -- http://mail.python.org/mailman/listinfo/python-list

Re: Improving interpreter startup speed

On 29 Okt, 13:55, [EMAIL PROTECTED] wrote: > Terry Reedy: > > > The current developers, most of whom use Python daily, [...] > > Thank you for bringing some light in this thread so filled with worse > than useless comments. Indeed. Observing that CGI is old-fashioned, aside from not really helping

Re: Improving interpreter startup speed

2008/10/27 James Mills <[EMAIL PROTECTED]>: > On Mon, Oct 27, 2008 at 5:40 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: >> Depends on the tool: build tool and source control tools are example >> it matters (specially when you start interfaciing them with IDE or >> editors). Having fast command l

Re: Improving interpreter startup speed

Terry Reedy: > The current developers, most of whom use Python daily, [...] Thank you for bringing some light in this thread so filled with worse than useless comments. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list

Re: Improving interpreter startup speed

Maybe Ruby is the right language for your need. Just sayin'. On Sun, 2008-10-26 at 13:19 +, Pedro Borges wrote: > The scripts i need to run but be executed with no apparent delay > specially when the text transforms are simple. > > > On Oct 26, 2008, at 11:13 AM, James Mills wrote: > >

Re: Improving interpreter startup speed

On Wed, Oct 29, 2008 at 9:43 PM, Lie <[EMAIL PROTECTED]> wrote: > On Oct 27, 2:36 pm, Paul Rubin wrote: >> It's not optimal but it is very common (CGI for example). > > CGI? When you're talking about CGI, network traffic is simply the > biggest bottleneck, not something l

Re: Improving interpreter startup speed

On Oct 27, 2:36 pm, Paul Rubin wrote: > "James Mills" <[EMAIL PROTECTED]> writes: > > Heaven knows! I hardly think invoking hundreds > > and possibly thousands of short-lived python > > interpreters to be an optimal solution that may > > have spawned this particular threa

Re: Improving interpreter startup speed

James Mills wrote: So instead of coming up with arbitary problems, why don't we come up with solutions for "Improving Interpreter Startup Speeds" ? The current developers, most of whom use Python daily, are aware that faster startup would be better. 2.6 and 3.0 start up quicker because the s

Re: Improving interpreter startup speed

David Cournapeau wrote: On Mon, Oct 27, 2008 at 2:36 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: It this a theoretical problem or an actual one, that we might have other suggestions for? Any command line based on python is a real example of that problem. No it is not. The specific problem tha

Re: Improving interpreter startup speed

To make faster python, you can do: 1.) Use mod_python, and not cgi. 2.) Use other special python server that remaining in memory, and call it from compiled C code. For example, the C code communicate this server with pipes, tcp, (or with special files, and the result will come back in other fi

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 5:46 PM, Gabriel Genellina <[EMAIL PROTECTED]> wrote: >> +1 This thread is stupid and pointless. >> Even for a so-called cold startup 0.5s is fast enough! > > I don't see the need to be rude. > And I DO care for Python startup time and memory footprint, and others do > too.

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 5:40 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Depends on the tool: build tool and source control tools are example > it matters (specially when you start interfaciing them with IDE or > editors). Having fast command line tools is an important feature of > UNIX, and

Re: Improving interpreter startup speed

En Sun, 26 Oct 2008 23:52:32 -0200, James Mills <[EMAIL PROTECTED]> escribió: On Mon, Oct 27, 2008 at 4:12 AM, Benjamin Kaplan <[EMAIL PROTECTED]> wrote: You must be in a real big hurry if half a second matters that much to you. Maybe if it took 5 seconds for the interpreter to start up, I

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 5:36 PM, Paul Rubin <"http://phr.cx"@nospam.invalid> wrote: > It's not optimal but it is very common (CGI for example). Which is why we (The Python Community) created WSGI and mod_wsgi. C"mon guys these "problems" are a bit old and out dated :) --JamesMills -- -- -- "Pro

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 4:33 PM, James Mills <[EMAIL PROTECTED]> wrote: > Yes, but in most cases you are not invoking your > command-line app x times per y units of time. Depends on the tool: build tool and source control tools are example it matters (specially when you start interfaciing them wit

Re: Improving interpreter startup speed

"James Mills" <[EMAIL PROTECTED]> writes: > Heaven knows! I hardly think invoking hundreds > and possibly thousands of short-lived python > interpreters to be an optimal solution that may > have spawned this particular thread. It's not optimal but it is very common (CGI for example). -- http://mai

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 5:28 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Any command line based on python is a real example of that problem. > There are plenty of them. Yes, but in most cases you are not invoking your command-line app x times per y units of time. --JamesMills -- -- -- "Pr

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 3:36 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > It this a theoretical problem or an actual one, that we might have other > suggestions for? Heaven knows! I hardly think invoking hundreds and possibly thousands of short-lived python interpreters to be an optimal solution t

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 2:36 PM, Terry Reedy <[EMAIL PROTECTED]> wrote: > > It this a theoretical problem or an actual one, that we might have other > suggestions for? Any command line based on python is a real example of that problem. There are plenty of them. David -- http://mail.python.org/mai

Re: Improving interpreter startup speed

David Cournapeau wrote: On Mon, Oct 27, 2008 at 10:52 AM, James Mills <[EMAIL PROTECTED]> wrote: On Mon, Oct 27, 2008 at 4:12 AM, Benjamin Kaplan +1 This thread is stupid and pointless. Even for a so-called cold startup 0.5s is fast enough! Not if the startup is the main cost for a command you

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 3:15 PM, David Cournapeau <[EMAIL PROTECTED]> wrote: > Not if the startup is the main cost for a command you need to repeat many > times. Seriously if you have to spawn and kill python processes that many times for an initial cold startup and subsequent warm startups to be

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 10:52 AM, James Mills <[EMAIL PROTECTED]> wrote: > On Mon, Oct 27, 2008 at 4:12 AM, Benjamin Kaplan > +1 This thread is stupid and pointless. > Even for a so-called cold startup 0.5s is fast enough! Not if the startup is the main cost for a command you need to repeat many t

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 3:45 AM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > Pedro was talking about cold startup time: > > $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches" > $ time python -c "pass" > > real0m0.627s > user0m0.016s > sys 0m0.008s $ sudo sh -c "echo 3 > /proc/sys/vm/dro

Re: Improving interpreter startup speed

On Mon, Oct 27, 2008 at 4:12 AM, Benjamin Kaplan <[EMAIL PROTECTED]> wrote: > You must be in a real big hurry if half a second matters that much to you. > Maybe if it took 5 seconds for the interpreter to start up, I could > understand having a problem with the start up time. +1 This thread is stu

Re: Improving interpreter startup speed

On Sun, Oct 26, 2008 at 11:19 PM, Pedro Borges <[EMAIL PROTECTED]> wrote: > The scripts i need to run but be executed with no apparent delay specially > when the text transforms are simple. That makes no sense whatsoever! If you are performing data conversion with Python, interpreter startup time

Re: Improving interpreter startup speed

Benjamin Kaplan wrote: I disagree. The extra time Python takes to start makes it unsuitable for many uses. For example, if you write a simple text editor then Pythons longer startup time might be to much. You must be in a real big hurry if half a second matters that much to you. M

Re: Improving interpreter startup speed

On Sun, Oct 26, 2008 at 1:45 PM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > 2008/10/26 James Mills <[EMAIL PROTECTED]>: > > On Sun, Oct 26, 2008 at 11:23 AM, BJörn Lindqvist <[EMAIL PROTECTED]> > wrote: > >> How are you getting those numbers? 330 μs is still pretty fast, isn't > >> it? :) Most d

Re: Improving interpreter startup speed

2008/10/26 James Mills <[EMAIL PROTECTED]>: > On Sun, Oct 26, 2008 at 11:23 AM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: >> How are you getting those numbers? 330 μs is still pretty fast, isn't >> it? :) Most disks have a seek time of 10-20 ms so it seem implausible >> to me that Ruby would be ab

Re: Improving interpreter startup speed

Pedro Borges <[EMAIL PROTECTED]> writes: > The scripts i need to run but be executed with no apparent delay > specially when the text transforms are simple. Basically you should keep the interpreter running and the script in memory in that case. -- http://mail.python.org/mailman/listinfo/python-li

Re: Improving interpreter startup speed

The scripts i need to run but be executed with no apparent delay specially when the text transforms are simple. On Oct 26, 2008, at 11:13 AM, James Mills wrote: On Sun, Oct 26, 2008 at 11:23 AM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: How are you getting those numbers? 330 μs is still pr

Re: Improving interpreter startup speed

On Sun, Oct 26, 2008 at 11:23 AM, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > How are you getting those numbers? 330 μs is still pretty fast, isn't > it? :) Most disks have a seek time of 10-20 ms so it seem implausible > to me that Ruby would be able to cold start in 47 ms. $ time python -c "pas

Re: Improving interpreter startup speed

Pedro Borges wrote: Hi guys, Is there a way to improve the interpreter startup speed? In my machine (cold startup) python takes 0.330 ms and ruby takes 0.047 ms, after cold boot python takes 0.019 ms and ruby 0.005 ms to start. You of course mean CPython, but Version, version, what Version?

Re: Improving interpreter startup speed

2008/10/25 Pedro Borges <[EMAIL PROTECTED]>: > Is there a way to improve the interpreter startup speed? > > In my machine (cold startup) python takes 0.330 ms and ruby takes > 0.047 ms, after cold boot python takes 0.019 ms and ruby 0.005 ms to > start. How are you getting those numbers? 330 μs is

Re: Improving interpreter startup speed

On Sat, 25 Oct 2008 12:32:07 -0700, Pedro Borges wrote: > Hi guys, > > > Is there a way to improve the interpreter startup speed? Get a faster computer? > In my machine (cold startup) python takes 0.330 ms and ruby takes 0.047 > ms, after cold boot python takes 0.019 ms and ruby 0.005 ms to s

Re: Improving interpreter startup speed

On Sat, 25 Oct 2008 12:32:07 -0700, Pedro Borges wrote: > Hi guys, > > > Is there a way to improve the interpreter startup speed? > > In my machine (cold startup) python takes 0.330 ms and ruby takes 0.047 > ms, after cold boot python takes 0.019 ms and ruby 0.005 ms to start. > > > TIA um.