Path: csiph.com!fu-berlin.de!uni-berlin.de!not-for-mail
From: Terry Reedy <tjreedy@udel.edu>
Newsgroups: comp.lang.python
Subject: Re: The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)
Date: Mon, 21 Mar 2016 20:13:01 -0400
Lines: 59
Message-ID: <mailman.473.1458605590.12893.python-list@python.org>
References: <mailman.8.1457732171.12893.python-list@python.org> <nbvqg5$3cm$1@dont-email.me> <mailman.23.1457749230.12893.python-list@python.org> <56e44258$0$1598$c3e8da3$5496439d@news.astraweb.com> <mailman.46.1457819135.12893.python-list@python.org> <8737rvxs89.fsf@elektro.pacujo.net> <nc2a7s$6dv$1@dont-email.me> <mailman.48.1457831488.12893.python-list@python.org> <nc4ffn$f6s$1@dont-email.me> <56e7483d$0$1608$c3e8da3$5496439d@news.astraweb.com> <nc7kjr$jj8$1@dont-email.me> <ncnhp9$tt7$1@dont-email.me> <mailman.426.1458526919.12893.python-list@python.org> <ncopi1$vgc$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
In-Reply-To: <ncopi1$vgc$1@dont-email.me>
Precedence: list
Xref: csiph.com comp.lang.python:105417

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