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

[Chris Angelico]

On Thu, Mar 24, 2016 at 12:41 AM, BartC <bc at freeuk.com> wrote:
> To extend this analogy better, executing byte-code to directly perform a
> task itself might be equivalent to travelling on foot, while everyone is
> suggesting taking the bus, tube or taxi.
>
> But when you are on foot, it might be worth looking at what's slowing you
> down, or indeed at whether you are actually being slowed down at all. With
> walking it's easy because 3mph is typical, you'll know when something is
> obviously wrong (dragging or carrying a huge amount of baggage with you for
> example). Running byte-code is not so obvious.
>

It's easy to see that carrying five boxes of books will slow down
you're walking *dramatically*. In fact, it's probably quicker to take
just one of them, and then come back for another one, and so on. When
you travel by car, it's much harder to measure the cost of the five
boxes, but it made so much difference in walking time that you should
probably take one box at a time, right?

This is how you're currently evaluating Python. Instead of starting
with the most simple and obvious code and refining from there, you're
starting from a whole lot of preconceived ideas about what's "fast" or
"slow", and assuming/expecting that they'll all still be valid. Many
of them won't be, yet you still persist in doing things based on what
you expect to be the case (because of what's fast/slow in C or some
other language). We've explained this a number of times, and one by
one, we're coming to the conclusion that you not only don't understand
Python, you don't *want* to understand Python; and until you actually
understand how the language works, timing stats are dubious.

Do you understand why people aren't taking your results very seriously?

ChrisA