The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
Terry Reedy
tjreedy at udel.edu
Mon Mar 21 20:13:01 EDT 2016
More information about the Python-list mailing list
Mon Mar 21 20:13:01 EDT 2016
- Previous message (by thread): The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
- Next message (by thread): The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 3/21/2016 8:34 AM, BartC wrote: > On 21/03/2016 02:21, Terry Reedy wrote: >> On 3/20/2016 9:15 PM, BartC wrote: >>> http://pastebin.com/dtM8WnFZ >>> This is a test of a character-at-a-time task in Python; >> >> I disagree. It tests of C code re-written in ludicrously crippled >> Python. No use of the re module, > > You can't use the re module for this kind of test. It would be like a > writing a C compiler in Python like this: > > system("gcc "+filename) I disagree. The re module is an integral part of python, as delivered, not an external program. It is included (and the core written in C) *because* it is needed to do certain tasks with reasonable speed. Would you say that one cannot use re syntax in a Perl program? The decision to access the functions via syntax rather than import should not determine the answer. > (or whatever the equivalent is in Python) and claiming the compilation > speeds are due to Python's fast byte-code. > >> designed for tasks like this, > > (I've tested someone's parser written in Python using regular > expressions, I seem to remember it was still pretty slow.) I would be flabbergasted is recognizing floats with an re was slower than doing so with several lines of Python, as you did. >> For instance, there are about 15 clauses like >> --- >> elif c=="?": >> lxsymbol=question_sym >> return >> --- >> >> I believe it would be much faster to combine these in one clause. First >> define simple_symbols = {'?': question_sym, ...}. Then >> elif c in simple_symbols: >> lxsymbol = simple_symbols[c] >> return > > I tried that (for 11 clauses), and it actually got a bit slower if the > one test was placed towards the end! But faster if placed nearer the > beginning. I would want to test the dict lookup directly against the equivalent if chain. But the placement issue is one I did not directly address. To optimize a series of conditional clauses, one must order according to frequency of truthfulness and time of execution. Unless one is unlucky, dict lookup should be overall constant regardless of insertion order. -- Terry Jan Reedy
- Previous message (by thread): The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
- Next message (by thread): The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-list mailing list