disassembled

If we use the disassembler for Python ( dis) , we see that all 3 compile to the same amount of instructions, and only differ in the POP_JUMP_IF_TRUEoPOP_JUMP_IF_FALSE

!=
              0 LOAD_FAST                0 (x)
              3 LOAD_CONST               1 ('val')
              6 COMPARE_OP               3 (!=)
              9 POP_JUMP_IF_FALSE       15

not ==
              0 LOAD_FAST                0 (x)
              3 LOAD_CONST               1 ('val')
              6 COMPARE_OP               2 (==)
              9 POP_JUMP_IF_TRUE        15

== else
              0 LOAD_FAST                0 (x)
              3 LOAD_CONST               1 ('val')
              6 COMPARE_OP               2 (==)
              9 POP_JUMP_IF_FALSE       15

Demo en ideone

profile

Using cProfile , we can measure the execution time and perform a benchmark :

          ncalls  tottime  percall  cumtime  percall filename:lineno(function)
not ==   5000000    1.589    0.000    1.589    0.000 ./prog.py:8(en)
== else  5000000    1.562    0.000    1.562    0.000 ./prog.py:12(ee)
!=       5000000    1.508    0.000    1.508    0.000 ./prog.py:4(ne)

Sorted from slowest to fastest, we can see that:

• if not x == 'val'it is the slowest.
• if x == 'val'+ elseis ~ 1.7% faster.
• if x != 'val'it's ~ 3.6% even faster.
• Between the slowest and the fastest we only save 81ms / 5 million comparisons.

Demo en ideone

_{* Or here is a more complex example to compare true and false cases with random strings.}

conclusion

The condition if x != 'val'is slightly more efficient.

However, in my opinion, the difference is not significant enough to change the style when coding. I absolutely prefer the code to be as easy to read as possible, and I would only think of taking this result into account in extremely intensive calculations that require saving every possible fraction of a second.

All three take the same

Benchmarking is not easy

All three do the same from the point of view of observable behavior. The python compiler or interpreter could therefore generate/execute exactly the same code in all three cases. In which case it would take exactly the same time to execute because it is the same generated code. And the observable differences would be noise.

One might be tempted to disassemble the generated code and see that it is different in all three cases. But the conclusions obtained in this way would only be applicable to the version of python with which the tests have been done. They would not be applicable in general.

Let's observe how using two different methods of executing these instructions we obtain different results. Let us consider the following program:

import time

def not_igual():
  if not x == 'val':
    x

def distinto():
  if x != 'val':
    x
    
def igual_else():
  if x == 'val':
    pass
  else:
    x
    
def test(tam):
 
 inicio = time.time()
 i = 0
 while (i<tam) :
   i = i + 1
 fin = time.time()
 vacio = fin-inicio
 
 inicio = time.time()
 i = 0
 while (i<tam) :
   not_igual()
   i = i + 1
 fin = time.time()
 print( 'Tiempo not ==  es ' + str(fin-inicio-vacio)  )

 inicio = time.time()
 i = 0
 while (i<tam) :
   distinto()
   i = i + 1
 fin = time.time()
 print( 'Tiempo !=      es ' + str(fin-inicio-vacio)  )
 
 inicio = time.time()
 i = 0
 while (i<tam) :
   igual_else()
   i = i + 1
 fin = time.time()
 print( 'Tiempo == else es ' + str(fin-inicio-vacio)  )

x='val'
test(10000000) 

When executing it with the python interpreter these are the results obtained:

jose2@HP-Negro:~/t$ python a.py
Tiempo not ==  es 1.71001195908
Tiempo !=      es 1.9246609211
Tiempo == else es 1.75712680817

And if I run it multiple times I get similar results. It looks like the winner is not == .

Now I compile it to C with cpython. And the C code I compile to an ELF binary for linux that I execute:

jose2@HP-Negro:~/t$ gcc -O2 -I /usr/include/python3.5m -o a a.c -lpython3.5m -lpthread -lm -lutil -ldl
jose2@HP-Negro:~/t$ ./a
Tiempo not ==  es 0.6007065773010254
Tiempo !=      es 0.6298408508300781
Tiempo == else es 0.6232995986938477
jose2@HP-Negro:~/t$ ./a
Tiempo not ==  es 0.5901763439178467
Tiempo !=      es 0.6861095428466797
Tiempo == else es 0.6084094047546387
jose2@HP-Negro:~/t$ ./a
Tiempo not ==  es 0.6090543270111084
Tiempo !=      es 0.6182305812835693
Tiempo == else es 0.6077189445495605

Now sometimes one wins and other times another wins.

But not only can I get different results with different execution environments. With the same execution environment the results can be different depending on the input data. Let's change the line x='val'to x='xxx'and run again with the interpreter:

jose2@HP-Negro:~/t$ gedit a.py
jose2@HP-Negro:~/t$ python a.py
Tiempo not ==  es 2.22967505455
Tiempo !=      es 2.49930405617
Tiempo == else es 2.18658304214

Now it is == else that wins. And when executing it several times this result is repeated. And I'm running it with exactly the same system where before the winner was not == , only the input has changed.

And none of the above benchmarks are good. In all tests the value of xis always the same from the beginning to the end of the test. It would also be necessary to test with random data or, better yet, with data obtained from a situation similar to the one that our program is expected to run. We can find surprises such as ordered data being processed faster than random data ; thus removing all value to an excessively simple benchmark as presented above.

I think that it is not necessary to compare these comparison operators to determine if one is much more efficient than another, basically because the computation is done so fast that it is almost impossible to detect a difference.

However, in my opinion there are differences when making comparisons with one or the other.

In theory, use

x != z

is more efficient than using

not x == val

The main reason is because != does the comparison directly and asks if x is different from z . Instead, not x == z performs two operations instead of one, because it first checks whether x is equal to z and then negates the result of that operation.

On the other hand, we must take into account the context in which we are making the comparison, in fact, the use of one or the other depends on that. What I mean by this is that there are times when it is much clearer to read and interpret a piece of code with the use of not than with the use of != , an example:

valid = 1 > 2; // false

I find the following line of code more readable:

if not valid:
  ...

what is this:

if valid != true:
  ...

And since I am talking about code readability, I would advise not to use reserved words like pass or break because they interrupt the flow of code in a somewhat abrupt way and make it difficult to read, making it complex and incomprehensible. . So much so, that some consider it the Spaghetti Code .

The differences in time I got were extremely minimal, using the following algorithm:

import time, array
#Las pruebas las realicé con cada una de las dos siguientes líneas:
#x,y = 'val','lav'
#x,y = 'va1','lav'

print (x,y)
t = array.array('d')
suma = 0

for j in range(0,100):
    ti = time.process_time()

    for i in range (0,100000):
        if x == 'val':    # not x == 'val'    # x != 'val'
            y = 'val'

    tf = time.process_time()

    dif = tf - ti
    t.append(dif)

    suma += dif

print ('Promedio = ', suma / 100)

The average was between 12 and 14 thousandths of a second, with if TRUE; and between 9 and 13 milliseconds, with if FALSE.

The positions from fastest to slowest were as follows:

if TRUE

1. if x == 'val'
2. if x != 'val'
3. if not x == 'val'

if FALSE

1. if x != 'val'
2. if not x == 'val'
3. if x == 'val'

According to the Python Data Model__ne__ , if a class does not implement the method , it delegates to the method __eq__. Therefore it is assumed more efficient to check a == bthan to check a != b.

On the other hand, a check if notis considered a single atomic operation, by design, not because of quirks of the interpreter implementation (as suggested in some comment), just as the not a is band operations were decided to be equivalent a is not b.

So the correct answer should be more efficient if not x == y. But this is not true with python native types , since they usually have all the methods of the data model implemented, in addition to their invocation being much more optimized compared to user-created methods.

My advice is not to obsess about performance since the improvements come from elsewhere, such as the variables to be compared being local (instead of using global ones) or generating expressions being combined with the functions any()or all()instead of the typical loops with some if.

In my opinion both are the same function, it happens that in the first:

if not x == 'val':

You are conditioning the statement of the condition to negation, that is, if it is NOT true that X is equal to val then do something, run the if, otherwise if it is true that X is VAL then do something else

in the second

if x != 'val':

You are doing the same but you say:

If X is different from VAL then do something else if X is not equal to VAL then do something else

I seem to work with the method of != different from . since you do not condition from the beginning to negate the entire statement that is in the IF

Additionally, reading about how python works with these two comparators, the first converts it to a boolean, why? Why will it ask the object "Is the logical condition met or not?"

and the second will ask "Are you equal to this value?"

As for your example:

if x == 'val':
pass
else:

you are declaring if X is equal to the Value do something, the method to use would be based on your need.

to know if the value is equal to the variable to enter the system, X == val

I'm going to give you an answer not based on disassembly, nor time analysis...

As a python programmer, that's pretty much the same to you, 99.99% of the time. It's very rare that something like this is going to affect the speed of your script. In fact, it is even detrimental to waste time on these "micro-optimizations", since there are probably other possible improvements at the algorithmic level.

Even with more complex operations, such as string concatenations, the gains are usually negligible.