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

[Chris Angelico]

On Tue, Mar 8, 2016 at 5:34 AM, BartC <bc at freeuk.com> wrote:
> On 07/03/2016 15:31, Chris Angelico wrote:
>>
>> On Tue, Mar 8, 2016 at 12:25 AM, BartC <bc at freeuk.com> wrote:
>
>
>>> (The Python version of that program is here:
>>> http://pastebin.com/cHx3UhQb. It should work with any Python.)
>>
>>
>> Actually, it won't work with any Python - not if it gets a broken
>> file. Your abortjpeg() function doesn't work :)
>
>
> What does it do when it doesn't work? I just get 'can't load file' then it
> stops if there's no such file. With an extra message if there's a format
> error. (I'm not sure what 'raise' does, but it doesn't complain about it. I
> think I realised I didn't know what came next and left it.)

Here's your code:

def abortjpeg(mess):
    print ("Error:",mess)
    raise

Here's my Python:

$ python3
Python 3.6.0a0 (default:bbfbde6ee9d0, Feb 19 2016, 12:43:06)
[GCC 5.3.1 20160121] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> raise
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: No active exception to reraise

The only try/except in your code (an except block is the only way
you'll have an "active exception") is this abomination:

def getfile(file):
    try:
        data=open(file,"rb").read()
    except:
        return 0
    ...

>> But what you have there is a messy mixture of old-style classes used
>> as if they were C structs, array.array() as if it were a C array, and
>> utterly uncommented code that looks like it was ported from, again, C.
>> Benchmarking Py2 vs Py3 on that kind of code is like trying to figure
>> out whether it's easier to drag a 747 by your teeth or your toes.
>> Yeah, you might get a result, but it's a useless one.
>
>
> 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. You haven't actually shown how a
properly-written program would perform.

>> You're not going to prove anything useful about Python - any version
>> of Python - by using it badly. Try implementing JPEG decoding in a
>> more Pythonic way - or, better still, use pillow and don't write that
>> kind of code yourself at all.
>
> Before I wrote this, I looked at three other existing Python decoders, all
> more Pythonic (one had been ported from C++ I think and was crammed full of
> classes).
>
> One worked so poorly that it was dismissed. The other two were full of bugs
> and didn't fully support the 3 main colour formats, but when they did work,
> were 3-6 times slower than my version IIRC.
>
> They also only worked with Python 2 (so presumably would have been even
> slower on 3!) It also meant I couldn't test PyPy on them. I tried psyco but
> it made little difference. And actually the main purpose was to have
> something substantial to try PyPy on.
>
> So I don't know who's using Python more badly: me or those other authors.

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'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? 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".

ChrisA