On Oct 27, 2:36 pm, Paul Rubin http://[EMAIL PROTECTED] 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 thread.
It's not
On Wed, Oct 29, 2008 at 9:43 PM, Lie [EMAIL PROTECTED] wrote:
On Oct 27, 2:36 pm, Paul Rubin http://[EMAIL PROTECTED] 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 like
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:
On
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
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 line tools
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
Tried using the precache daemon to see if it gives any boost?
--
http://mail.python.org/mailman/listinfo/python-list
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
editors). Having
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
--
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 that
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
--
--
--
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).
--
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 with
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. Cmon guys
these problems are a bit old and out
dated :)
--JamesMills
--
--
-- Problems
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
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 if
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. Even if
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
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 that
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
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 pass
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
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-list
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 able to cold
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 disks have a
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.
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 times
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 stupid
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/drop_caches
$ time
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
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
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
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
--
http://mail.python.org/mailman/listinfo/python-list
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... does
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 start.
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 still
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?
37 matches
Mail list logo