Pyhon 2.x or 3.x, which is faster?

[BartC]

On 07/03/2016 19:10, Chris Angelico wrote:
> On Tue, Mar 8, 2016 at 5:34 AM, BartC <bc at freeuk.com> wrote:

> def abortjpeg(mess):
>      print ("Error:",mess)
>      raise
>
> Here's my Python:

> RuntimeError: No active exception to reraise

OK I'll have a look. (Or maybe just change 'raise' to 'exit(0)'. It just 
needs to crash out at this point, but should be a bit more graceful than 
what you had.)

>> I disagree. The program does its job perfectly (you will have to take it
>> further to verify the results, such as writing out the .ppm file and viewing
>> the contents).
>>
>> But Py3 is slower doing this task than Py2 by 10 or 20% (or even 30% for a
>> smaller file). /This is in line with other observations./
>
> What's your meaning of "perfectly"? You're implementing things in a
> very C way, and then showing that two different Python interpreters
> have different performance.

Two interpreters executing exactly the same code and exactly the same 
algorithm. And for a real task which deliberately doesn't just delegate 
to high-level features (otherwise you're just comparing libraries).

What can be more perfect for comparing two implementations?

> You haven't actually shown how a
> properly-written program would perform.

If I could find one that worked, I would have used that! (But I was more 
interested in 3 vs. PyPy than 2 vs. 3.)

> Did you try the 'pillow' library?
>
> https://pypi.python.org/pypi/Pillow
>
> It supports 2.6/2.7 and 3.2+, and would be most people's "one obvious
> way" to do things. At very least, it should get a mention in your
> performance comparisons.

I don't understand. This is an external library that appears to be 
written in C. How does that help me compare the performance of two 
implementations of Python?

One could be ten times slower than the other (in executing its native 
bytecode), but if it spends 99% of its time an a C image library, how do 
you measure that?

>> (I'm quite pleased with my version: smaller, faster, works on all the
>> Pythons, supports all 3 colour formats and no decoding bugs that I'm aware
>> of, and it's the first Python program I've written that does something
>> useful.)
>
> "all the Pythons" meaning what, exactly?

I means versions 2 and 3 of the language, tested on CPython versions 
2.5, 2.7, 3.1 and 3.4, as well as PyPy. The other decoders I tried were 
for 2.x.

> And, no decoding bugs? Maybe,
> but I wouldn't bet my life on it. Unless your code is a pure port of
> someone else's (and unless that someone else could guarantee that the
> original C code was bug free), I wouldn't trust code that I can't
> completely analyze in one sitting. Virtually all code has bugs in it;
> the only code that doesn't is code that's so trivially simple that you
> can completely understand it in one "headspace".

Let's put it this way: I don't have to hand a jpeg file that it can't 
decode. When one turns up then I will fix that. (I can't say for sure 
there aren't any subtle chroma or quality problems, but there's nothing 
obvious.) I can't say that for the decoders I looked at.

-- 
Bartc