pointless musings on performance

Discussion in 'Python' started by mk, Nov 24, 2009.

  1. mk

    mk Guest

    #!/usr/local/bin/python

    import timeit


    def pythonic():
    nonevar = None
    zerovar = 0
    for x in range(1000000):
    if nonevar:
    pass
    if zerovar:
    pass

    def unpythonic():
    nonevar = None
    zerovar = 0
    for x in range(1000000):
    if nonevar is not None:
    pass
    if zerovar > 0:
    pass

    for f in [pythonic, unpythonic]:
    print f.func_name, timeit.timeit(f, number=10)



    # ./t.py
    pythonic 2.13092803955
    unpythonic 2.82064604759

    Decidedly counterintuitive: are there special optimizations for "if
    nonevar:" type of statements in cpython implementation?


    regards,
    mk
     
    mk, Nov 24, 2009
    #1
    1. Advertising

  2. mk

    Chris Rebert Guest

    On Tue, Nov 24, 2009 at 4:31 AM, Rob Williscroft <> wrote:
    > mk wrote in news: in
    > comp.lang.python:
    >
    >>
    >> def pythonic():

    >
    >> def unpythonic():

    >
    >
    >> Decidedly counterintuitive: are there special optimizations for "if
    >> nonevar:" type of statements in cpython implementation?
    >>

    >
    > from dis import dis
    >
    > dis( unpythonic )
    >
    > 18          31 LOAD_FAST                0 (nonevar)
    >             34 LOAD_CONST               0 (None)
    >             37 COMPARE_OP               9 (is not)
    >             40 JUMP_IF_FALSE            4 (to 47)
    >
    > dis( pythonic )
    >
    > 11          31 LOAD_FAST                0 (nonevar)
    >             34 JUMP_IF_FALSE            4 (to 41)


    In other words, CPython doesn't happen to optimize `if nonevar is not
    None` as much as it theoretically could (which would essentially
    require a JUMP_IF_NONE opcode). Since CPython isn't known for doing
    fancy optimizations, this isn't surprising.

    Cheers,
    Chris
    --
    http://blog.rebertia.com
     
    Chris Rebert, Nov 24, 2009
    #2
    1. Advertising

  3. mk

    Terry Reedy Guest

    Chris Rebert wrote:
    > On Tue, Nov 24, 2009 at 4:31 AM, Rob Williscroft <> wrote:
    >> mk wrote in news: in
    >> comp.lang.python:
    >>
    >>> def pythonic():
    >>> def unpythonic():

    >>
    >>> Decidedly counterintuitive: are there special optimizations for "if
    >>> nonevar:" type of statements in cpython implementation?
    >>>

    >> from dis import dis
    >>
    >> dis( unpythonic )
    >>
    >> 18 31 LOAD_FAST 0 (nonevar)
    >> 34 LOAD_CONST 0 (None)
    >> 37 COMPARE_OP 9 (is not)
    >> 40 JUMP_IF_FALSE 4 (to 47)
    >>
    >> dis( pythonic )
    >>
    >> 11 31 LOAD_FAST 0 (nonevar)
    >> 34 JUMP_IF_FALSE 4 (to 41)

    >
    > In other words, CPython doesn't happen to optimize `if nonevar is not
    > None` as much as it theoretically could (which would essentially
    > require a JUMP_IF_NONE opcode). Since CPython isn't known for doing
    > fancy optimizations, this isn't surprising.


    There is a limit of 256 bytecodes. I believe there are currently fewer.
    It would seem that adding bytecodes that combine current pairs would
    speed the interpreter, depending on how often the combined pair is used.
    And people have looked for frequent pairs across a corpus of code, and
    proposed additions.

    However, additional bytecodes enlarge the basic bytecode eval loop,
    possibly (and sometimes actually) leading to to more processor cache
    misses and slower execution. At least some proposed non-essential
    additions have been rejected for the reason.

    Also, even though CPython-specific bytecodes are outside the language
    definition, and could theoretically be revamped every minor (x.y)
    release, there is a cost to change. Rewrite the ast to bytecode
    compiler, rewrite dis, rewrite the dis doc, and burden anyone concerned
    with multiple versions to remember. So in practice, change is minimized
    and unassigned bytecodes are left open for the future.

    Optimizations that make better use of a fix set of bytecodes are a
    different topic. Guido is conservative because historically, compilier
    optimizations are too often not exactly equivalent to naive, obviously
    correct code in some overlooked corner case, leading to subtle,
    occasional bugs. Of course, byte code changes could mess-up current
    optimizations that are performed.

    Terry Jan Reedy
     
    Terry Reedy, Nov 24, 2009
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jsnX

    pointless object copies

    jsnX, Mar 31, 2005, in forum: C++
    Replies:
    1
    Views:
    435
    Victor Bazarov
    Mar 31, 2005
  2. Zach

    main prototype pointless?

    Zach, Feb 2, 2009, in forum: C Programming
    Replies:
    5
    Views:
    318
    jameskuyper
    Feb 2, 2009
  3. Antoine Pitrou

    Re: pointless musings on performance

    Antoine Pitrou, Nov 24, 2009, in forum: Python
    Replies:
    9
    Views:
    362
    Paul Boddie
    Nov 26, 2009
  4. John Carter
    Replies:
    3
    Views:
    141
    Brian Candler
    Jan 16, 2009
  5. Intransition

    FileUtils.mv Pointless Errno::ENOENT

    Intransition, Sep 6, 2009, in forum: Ruby
    Replies:
    2
    Views:
    183
    7stud --
    Sep 12, 2009
Loading...

Share This Page