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

--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to