Python Performance
Markus Stenberg
mstenber at cc.Helsinki.FI
Sun Jul 25 07:53:00 EDT 1999
More information about the Python-list mailing list
Sun Jul 25 07:53:00 EDT 1999
- Previous message (by thread): Python Performance
- Next message (by thread): Python Performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message (by thread): Python Performance
- Next message (by thread): Python Performance
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list