The Cost of Dynamism (was Re: Pyhon 2.x or 3.x, which is faster?)

BartC bc at freeuk.com
Mon Mar 21 12:51:30 EDT 2016


On 21/03/2016 16:30, Steven D'Aprano wrote:
> On Mon, 21 Mar 2016 06:47 pm, Ben Finney wrote:
>
>> Steven D'Aprano <steve+comp.lang.python at pearwood.info> writes:
>>
>>> On Monday 21 March 2016 13:11, Ben Finney wrote:
>>>> Please, stop making assertions about Python code until you have
>>>> learned Python.
>>>
>>> I don't see how "I don't have a clue about exceptions" is an assertion
>>> about Python code.
>>
>> That's not the assertion. I'm asking Bart to acknowledge that, because
>> of the ignorance he admits to above, he should not be making elsewhere
>> the sky-is-falling assertions about Python's failings.
>
> I haven't seen these assertions that the sky is falling. What I have seen is
> some benchmarks which purport to show that Python performs poorly compared
> to Bart's custom language, which he describes as "dynamic", and Bart trying
> to understand the design decisions which lead to this poor performance.
>
> In fact, Bart even described one of those benchmarks as demonstrating that
> Python was fast enough to be usable for typical tasks he performs (albeit
> at the slow end of usable), so I believe that he is writing them in good
> faith.

Yes, on my machine even Python 3 can apparently tokenise C at around 40K 
lines per second. But this varies depending on the density of the 
source. On other inputs, it might achieve over 50Klps. And this was the 
slowest of the Pythons tested; others will be faster. My machine isn't 
the fastest either.

So, even though this test only does the lowest level of tokenising (the 
next steps are doing name lookups, and then actual parsing), I think it 
is quite practical to use Python in tasks like this.

(Note that my gcc C compiler can only compile at 2-5 Klps, peaking at 
12Klps with input in one large. Compared to that, the Python timing 
isn't too bad.)

-- 
Bartc



More information about the Python-list mailing list