Movatterモバイル変換

Performance measurements (was: python on the smalltalk VM)

• Previous message (by thread):Newbie Quest. KSpread/Python
• Next message (by thread):BUY AND SELL ALMOST ANYTHING ONLINE
• Messages sorted by:[ date ][ thread ][ subject ][ author ]

Douglas Alan wrote:>All this should come as no shock -- 100 times slower for an>interpreted language is just par for a good interpreter.  Before the>spiffy Self compiler, state of the art was 10x slower than C for a>really bitchin' highly optimized Smalltalk compiler.I have a package called PyDaylight which puts a deep Pythonlayer (with OO, exceptions, iterators, etc) on top of a C libraryfor chemical informatics.  I've done a lot of timing tests onthe library to see how the Python code compares to morallyequivalent C code.In most cases it's about a factor of ten.  The fastest caseis a 50% slowdown for code which is mostly in the extension -and it should be faster now that Python has xreadlines.  Theslowest case was a factor of 40 for code which did a lotof array lookup and used the __getattr__ hooksMy timing tests have put Python code anywhere from 50% slowerthan C code (when most of the work was done in a C extension)to 40x.  This slowest case was for code that did a lot of listlookups instead of pointer increments, and used the objectlayer heavily, which is translates attribute lookups to theC level via getattr calls.Most code is O(10x) slower.  Of course, to balance it outin most cases the code itself is an order of magnitude fewerlines of code and an order of magnitude easier to read.So I don't agree with your estimate of 100x slower, at leastfor the domain of programs I've investigated.                    Andrewdalke at acm.org

• Previous message (by thread):Newbie Quest. KSpread/Python
• Next message (by thread):BUY AND SELL ALMOST ANYTHING ONLINE
• Messages sorted by:[ date ][ thread ][ subject ][ author ]