Why is my "exploded" Python code actually running faster?

Question

I'm in an introductory comp-sci class (after doing web programming for years) and became curious about how much speed I was gaining, if any, with my one-liners.

for line in lines:
  numbers.append(eval(line.strip().split()[0]))

So I wrote the same thing with painfully explicit assignments and ran them against each other.

for line in lines:
  a = line.split()
  b = a[0]
  c = b.strip()
  d = eval(c)
  numbers.append(d)

The second one runs a consistent 30ms faster (on my FreeBSD shell account; see Edit #2) with an input file of 100K lines! Of course this is on a total run time of 3 seconds, so the percentage isn't large...but I'm really surprised to see all those explicit named assignments somehow helping.

There's a recent thread on the performance of functions as opposed to inline code, but this seems even more basic. What gives? Should I be writing lovingly fulsomely verbose code and telling my sneering colleagues it's for performance reasons? (Thankfully, a list-comprehension version runs about 10ms faster yet, so my cherished compactness isn't totally out the window.)

EDIT: Thanks for the tip on my sloppy expansion of the code. You're all correct that the second one should really be:

for line in lines:
  a = line.strip()
  b = a.split()
  c = b[0]
  d = eval(c)
  numbers.append(d)

However, even once I've fixed that, my timings are 2.714s, 2.652s, and 2.624s respectively, for the one-liner, the fully-exploded form, and the list comprehension (not pictured). So my question stands!

EDIT #2: It's interesting that the answer doesn't seem to be obvious even to a bunch of knowledgeable folks, which makes me feel a bit better about the question! I'll probably play with dis a bit on my own now, in this and similar circumstances, and see what turns up. By all means keep tinkering with the thread if you want, but I'm going to declare my received answer to be "huh, that's interesting; must be something deep." Especially since the behavior isn't consistent across machines, as steveha pointed out -- the slight difference goes the other direction on my Debian and Windows installs. Thanks to everyone who's contributed!

Answer 1

Frankly speaking, the first version, where everything is in one line, is a pain to read.
The second one is maybe a little too verbose (something in the middle would be appreciated) but it is definitely better.

I would not care too much about micro optimizations because of Python internals, and focus only on readable code.

By the way: the two (initial) versions are not doing the same thing.
In the former, you first strip, then split, while in the latter you first split and then strip (furthermore, only the first element).
Again, I think you overlooked this because the former version is quite difficult to focus on.
Then, analyzing the two (updated) versions with dis (python disassembler) showed no real difference between the two codes, only the order how the function names are being looked up. It is possible that this may have an impact on performance.

While we are on this, you could get some performance improvement just by binding eval to a local variable, before the loop. I would expect that after that change, there should be no difference in time between the two versions.
For example:

eval_ = eval
for line in lines:
    a = line.strip()
    b = a.split()
    c = b[0]
    d = eval_(c)
    numbers.append(d)

We are mostly talking about micro-optimizations, but this aliasing is actually a technique that may be very useful in several circumstances.

Answer 2

A one liner doesn't mean smaller or faster code. And I would expect that the eval() line would throw off performance measurements quite a bit.

Do you see similar performance differences without eval ?

Answer 3

Your code isn't exploded in the same order. The compact version goes:

A > B > C > D > E

while your exploded version goes

B > C > A > D > E

The effect is that strip() is being deferred 2 steps down, which may affect performance depending on what the input is.

Answer 4

The method calls are also not in the same order:

for line in lines:
    numbers.append(eval(line.strip().split()[0]))

should be:

for line in lines:
    numbers.append(eval(line.split()[0].strip()))

Answer 5

I agree with Roberto Liffredo; don't worry about that small of a performance improvement; code that is easier to understand, debug, and change is its own reward.

As for what's going on: the terse code and the expanded code don't do quite the same things. line.strip().split() first strips the line and then splits it; your expanded code splits the line first, and then calls strip() on the first word from the line. Now, the strip() isn't needed here; it's stripping white space from the end of the line, and words returned by split() never have any. Thus, in your expanded version, strip() has absolutely no work to do.

Without benchmarking, I can't be certain, but I think that strip() having no work to do is the key. In the one-line version, strip() sometimes has work to do; so it will strip the whitespace, building a new string object, and then return that string object. Then, that new string object will be split and discarded. The extra work of creating and discarding string objects is likely what is making the one-line solution slower. Compare that with the expanded version, where strip() simply looks at the string, decides it has no work to do, and returns the string unmodified.

In summary, I predict that a one-liner equivalent to your expanded code will be slightly faster than your expanded code. Try benchmarking this:

for line in lines:
  numbers.append(eval(line.split()[0].strip()))

If you want to be completely thorough, you could benchmark both versions with the strip() removed completely. You just don't need it. Or, you could pre-process your input file, making sure that there is no leading or trailing white space on any input line, and thus never any work for strip() to do, and you will probably see the benchmarks work as you would expect.

If you really want to make a hobby out of optimizing for speed here, you could call split with a "maxsplit" argument; you don't need to process the whole string as you are throwing away everything after the first split. Thus you could call split(None, 1). You can get rid of the strip(), of course. And you would then have:

for line in lines:
  numbers.append(eval(line.split(None, 1)[0]))

If you knew the numbers were always integers, you could call int() instead of eval(), for a speed improvement and security improvement.

Answer 6

Also, sometimes it's tricky to run benchmarks. Did you re-run the benchmarks multiple times and take the best of several runs? Is there any chance that caching effects give a performance advantage to the second Python program you run? Have you tried making your input file ten times bigger, so your program will take about ten times longer to run?

Answer 7

I haven't benchmarked it, but one factor in the time differences is that you have to do several variable lookups in the second function.

From Python Patterns - An Optimization Anecdote:

This is because local variable lookups are much faster than global or built-in variable lookups: the Python "compiler" optimizes most function bodies so that for local variables, no dictionary lookup is necessary, but a simple array indexing operation is sufficient.

So, local variable lookups do have a cost associated. Let's take a look at the disassembled functions:

First, making sure I have the same defined functions as you:

>>> def a(lines):
    for line in lines:
     numbers.append(eval(line.strip().split()[0]))

>>> def b(lines):
    for line in lines:
     a = line.strip()
     b = a.split()
     c = b[0]
     d = eval(c)
     numbers.append(d)

Now, let's compare their disassembled values:

>>> import dis
>>> dis.dis(a)
  2           0 SETUP_LOOP              49 (to 52)
              3 LOAD_FAST                0 (lines)
              6 GET_ITER            
        >>    7 FOR_ITER                41 (to 51)
             10 STORE_FAST               1 (line)

  3          13 LOAD_GLOBAL              0 (numbers)
             16 LOAD_ATTR                1 (append)
             19 LOAD_GLOBAL              2 (eval)
             22 LOAD_FAST                1 (line)
             25 LOAD_ATTR                3 (strip)
             28 CALL_FUNCTION            0
             31 LOAD_ATTR                4 (split)
             34 CALL_FUNCTION            0
             37 LOAD_CONST               1 (0)
             40 BINARY_SUBSCR       
             41 CALL_FUNCTION            1
             44 CALL_FUNCTION            1
             47 POP_TOP             
             48 JUMP_ABSOLUTE            7
        >>   51 POP_BLOCK           
        >>   52 LOAD_CONST               0 (None)
             55 RETURN_VALUE        
>>> dis.dis(b)
  2           0 SETUP_LOOP              73 (to 76)
              3 LOAD_FAST                0 (lines)
              6 GET_ITER            
        >>    7 FOR_ITER                65 (to 75)
             10 STORE_FAST               1 (line)

  3          13 LOAD_FAST                1 (line)
             16 LOAD_ATTR                0 (strip)
             19 CALL_FUNCTION            0
             22 STORE_FAST               2 (a)

  4          25 LOAD_FAST                2 (a)
             28 LOAD_ATTR                1 (split)
             31 CALL_FUNCTION            0
             34 STORE_FAST               3 (b)

  5          37 LOAD_FAST                3 (b)
             40 LOAD_CONST               1 (0)
             43 BINARY_SUBSCR       
             44 STORE_FAST               4 (c)

  6          47 LOAD_GLOBAL              2 (eval)
             50 LOAD_FAST                4 (c)
             53 CALL_FUNCTION            1
             56 STORE_FAST               5 (d)

  7          59 LOAD_GLOBAL              3 (numbers)
             62 LOAD_ATTR                4 (append)
             65 LOAD_FAST                5 (d)
             68 CALL_FUNCTION            1
             71 POP_TOP             
             72 JUMP_ABSOLUTE            7
        >>   75 POP_BLOCK           
        >>   76 LOAD_CONST               0 (None)
             79 RETURN_VALUE

It's a lot of information, but we can see the second method is riddled with STORE_FAST, LOAD_FAST pairs due to the local variables being used. That might be enough to cause your small timing differences, (perhaps) in addition to the different operation order as others have mentioned.

Answer 8

Okay, enough theorizing. I created a file with one million lines, with random amounts of white space (0 to 4 spaces, usually 0) at beginning and end of each line. And I ran your one-liner, your expanded version, and my own list comprehension version (as fast as I know how to make it).

My results? (Each one is the best of three trials):

one-line: 13.208s
expanded: 26.321s
listcomp: 13.024s

I tested under Ubuntu 9.04, 32-bit, with Python 2.6.2 (CPython, of course).

So I am completely unable to explain why you saw the expanded one running faster, given that it ran half as fast on my computer.

Here's the Python program I used to generate my test data:

import random

f = open("/tmp/junk.txt", "w")

r = random.Random()

def randws():
    n = r.randint(0, 10) - 4
    if n < 0 or n > 4:
        n = 0
    return " " * n

for i in xrange(1000000):
    s0 = randws()
    n = r.randint(0, 256)
    s1 = randws()
    f.write("%s%d%s\n" % (s0, n, s1))

Here's my list comprehension program:

lines = open("/tmp/junk.txt")

numbers = [eval(line.split(None, 1)[0]) for line in lines]

P.S. Here is a nice, fast version that can handle both int and float values.

lines = open("/tmp/junk.txt")

def val(x):
    try:
        return int(x)
    except ValueError:
        pass

    try:
        return float(x)
    except StandardError:
        return 0

numbers = [val(line.split(None, 1)[0]) for line in lines]

Its best-of-three time was: 2.161s