Python Performance

[Markus Stenberg]

gward at cnri.reston.va.us (Greg Ward) writes:
> sreekant kodela <sreekantk at freenet.co.uk> wrote:
> If you're concerned about runtime performance -- ie. how long it takes
> to mangle strings and loop over lists and so forth -- I wouldn't worry
> about it.  Yes, Python is slow, but the Internet is so much slower that
> it hardly matters.

Even in websites' case, I would worry; Python doesn't use multiCPU very
well, and with single CPU, it is fairly easy to saturate one with
pure-Python code, especially if it is badly designed to boot.

For AMD K6-2 300mhz, your mileage may vary:

Normal null method call :  156332.1874/sec [0.19s] (6.3966us/call)
(=simple, def foo(): pass call)
Apply null method call  :   39783.6246/sec [0.75s] (25.136us/call)
(=simple, foo-call using apply)

normal get    :  114632.8877/sec [0.79s] (8.7235us/call)
normal set    :  108738.4606/sec [0.83s] (9.1964us/call)
normal getattr:  106416.8282/sec [0.85s] (9.3970us/call)
normal setattr:  109442.3212/sec [0.82s] (9.1372us/call)

Admittedly, getting approx. 100+k attribute accesses /null calls off
doesn't sound bad, but once you start poking around with dbs:

Using a Gadfly database, _with_ pre-compiled queries: (very simple
one-liners from table with one entry)
select: 21.4182/sec [3.64s] (46.689ms/call)
update: 14.3209/sec [3.98s] (69.828ms/call)

.. and so on. Even more distressing results lie in the speed of say,
implementing protocols in Python (when we're talking _nearly_ realtime
action). 

Thus I've had great deal of interest in getting the speed up; however,
speeding up dynamic interpreted languages is nontrivial, especially
languages as dynamic as Python.

My interest in Python's speed originally stemmed from need to write some
protocols and parts of a game engine in Python, but for instance LOS
calculation purposes, Python seems simply too slow.

Disclaimer: I'm still interested in hearing solutions to the speed
problem. Exhibit #2:

P/UDP:snd+rcv               :     992.0708/sec [0.95s] (1.0080ms/call)
(=Python-based UDP echo client+server; 1000 roundtrips, not bad, eh?)

Writing a simple TCP-ish connection-oriented protocol on top of UDP:
P/FakeTCP:snd+rcv      :      95.0250/sec [0.93s] (10.524ms/call)

Although network traffic caused by (simplex) connection-oriented protocol
is virtually same as the UDP case's, protocol slows down 90% thanks to the
Python's CPU use.

And compare that to the real TCP:
P/TCP:snd+rcv               :    2367.1947/sec [1.00s] (422.44us/call)

I am fairly certain that if I bothered to implement the protocol in C, I'd
get N times as much speed with same machine,

- Speed-does-matter-ly yours, Markus

P.S. This might surface as one example for 'why scripting languages don't
always cut it' in my master's thesis; if I have made some grievous
error(s?), corrections are welcome. 

P.P.S. Too bad Python doesn't have anything that creates _nice_ code, like
Stalin for Lisp ;-)

-- 
----- BEGIN GEEK CODE v3.0 BLOCK (*) -----
GCS d- s+: !a C+(++) UL+++$ P--- L+++ E++ W-- N+ W--- O---- M-- V- PS+++
Y+ PGP++>+++ t+@ 5++ X+ R* tv-- b+++ DI+++>++++ D---- G++ e++ h* r% z+
----- END GEEK CODE v3.0 BLOCK -----
* For spoilers, check http://www.geekcode.com