Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #11984

Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1")

Show all headers | View raw

[Multipart message — attachments visible in raw view] - view raw

On 8/21/11 12:53 PM, Laurent wrote:
> 
>> With 64 bit 3.2.2 on my Win 7 Pentium, the difference was 4% and with 
>> floats (0.0 and 1.0), 6%
> 
> For floats it is understandable. But for integers, seriously, 4% is a lot. I would never have thought an interpreter would have differences like this in syntax for something as fundamental as adding 1.

Its, seriously, not even kind of a lot at all. Percentages without
context are meaningless: its 4% slower, sure -- but that is 4% of an
incredibly small probably constant-time amount of time.

Picking "i += 1" over "i = i + 1" based on one being 4% slower is sorta
kinda crazy. The difference in speed is probably related to churn and
cache as much as anything else (its not as consistent on my machine, for
example): or the ceval loop doing a few more case-tests between them as
others have mentioned. All in all, if 4% of a nanomicrofraction of a
chunk of time is that meaningful, you're probably best served not using
Python. :)

That said: my advice is always to avoid += like a plague. It is magic
and impossible to predict without intimate knowledge of exactly what's
on the left-side.

   i += 1
   n += x

Those two things look very similar, but they may do -completely-
different things depending on just what "n" is.

It may or may not do something that is like:

    n = n + x

Or, it may do something that's more akin to

    n.extend(x)
    n = n

Those aren't even kind of equivalent actions. And things get more
complicated if 'n' is say, n[0] (especially if something goes wrong
between the extend and the rebinding).

Python's usually all explicit and pretty well-defined in how its basic
syntax and behaviors operate, and you usually don't really have to know
details about how a data-type works to predict exactly what it's doing:
in fact, its often beneficial to not pay too much attention to such
details, and just assume the data type will work approximately as you'd
expect. That way people can slip something-something to you and wink and
say of /course/ its a dict, darling. Try it, you'll like it, okay? This
sorta thing is encouraged, but it kinda depends on trusting objects to
behave a certain way and for things to be predictable in both how they
work and how they fail.

With "i = i + 1", I know that generally speaking, my "i" is being
assigned a new object and that's that, no matter what type "i" is.
(Okay: I do know that you could modify __add__ to do something
underhanded here, tweaking internal state and then returning self.
People going out of their way to behave unpredictably is not my
objection: supposedly easy and straight-forward normal Python-fu being
inherently unpredictable is).

For example: I just /know/ that it doesn't matter who or what may have
their own binding to that object before I go and increment it, they
won't be affected and everything just will work fine. With augmented
assignment, I can't be sure of that. Now, while I admit, you generally
do have to keep track in your head of which of your data-types are
mutable vs immutable and take care with sharing mutables, the fact that
"n += x" is described and generally thought of as merely syntactical
sugar for:

   n = n + x

... lets one easily think that this should be entirely safe, even with
mutable objects, because if += were merely syntactical sugar, it would
be. But its not! Because += is wiggly. It can do more then one entirely
different kind of behavior.

Anyways. </rant> I've been kinda annoyed at augmented assignment for
years now :P

-- 

   Stephen Hansen
   ... Also: Ixokai
   ... Mail: me+list/python (AT) ixokai (DOT) io
   ... Blog: http://meh.ixokai.io/

Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-21 19:27 +0200
  Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 10:48 -0700
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 11:03 -0700
  Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Christian Heimes <lists@cheimes.de> - 2011-08-21 20:24 +0200
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Roy Smith <roy@panix.com> - 2011-08-21 14:52 -0400
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-22 01:17 +0200
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Chris Angelico <rosuav@gmail.com> - 2011-08-22 00:37 +0100
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 19:38 -0400
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-22 02:00 +0200
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Seebs <usenet-nospam@seebs.net> - 2011-08-22 05:33 +0000
  Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 15:39 -0400
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:53 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:55 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:55 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 11:12 +1000
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") "Richard D. Moores" <rdmoores@gmail.com> - 2011-08-22 02:55 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Emile van Sebille <emile@fenx.com> - 2011-08-22 09:35 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Emile van Sebille <emile@fenx.com> - 2011-08-22 10:22 -0700
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 13:04 -0700
    Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Laurent <laurent.payot@gmail.com> - 2011-08-21 12:53 -0700
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Andreas Löscher <andreas.loescher@s2005.tu-chemnitz.de> - 2011-08-22 01:25 +0200
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Chris Angelico <rosuav@gmail.com> - 2011-08-22 00:41 +0100
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 11:16 +1000
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Christian Heimes <lists@cheimes.de> - 2011-08-22 04:04 +0200
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Terry Reedy <tjreedy@udel.edu> - 2011-08-21 22:11 -0400
      Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Stephen Hansen <me+list/python@ixokai.io> - 2011-08-21 19:08 -0700
        Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-22 14:14 +1000
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Stephen Hansen <me+list/python@ixokai.io> - 2011-08-21 21:37 -0700
          Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") Stephen Hansen <me+list/python@ixokai.io> - 2011-08-21 21:49 -0700
  Re: relative speed of incremention syntaxes (or "i=i+1" VS "i+=1") casevh <casevh@gmail.com> - 2011-08-21 21:14 -0700

csiph-web