why does dead code costs time?

[Neil Cerutti]

On 2012-12-05, Bruno Dupuis <python.ml.bruno.dupuis at lisael.org> wrote:
> Hi,
>
> I'm interested in compilers optimizations, so I study python
> compilation process
>
> I ran that script:
>
>     import timeit
>
>     def f(x):
>         return None
>
>     def g(x):
>         return None
>         print(x)
>
>     number = 10000
>
>     print(timeit.timeit('f(1)',setup="from __main__ import f", number=number))
>     print(timeit.timeit('g(1)',setup="from __main__ import g", number=number))   
>
>     print(dis.dis(f))
>     print(dis.dis(g))
>
> It gives this output:
>
>     0.003460251959040761
>     0.004164454061537981
>      17           0 LOAD_CONST               0 (None) 
>                   3 RETURN_VALUE         
>     None
>      20           0 LOAD_GLOBAL              0 (None) 
>                   3 RETURN_VALUE         
>
>      21           4 LOAD_GLOBAL              1 (print) 
>                   7 LOAD_FAST                0 (x) 
>                  10 CALL_FUNCTION            1 (1 positional, 0 keyword pair) 
>                  13 POP_TOP              
>     None
>
> I do not understand why the dead code `print(x)` takes time (~20% in
> that case). As we see in the opcode, a call to g(1) returns immediately, so
> there should be no delay at all. Where am i wrong?
>
> mmhh... it comes to me now that the gap must be in function loading time...
> I'll check ceval.c
>
> However, isn't there a room for a slight optim here? (in this case, the
> dead code is obvious, but it may be hidden by complex loops and
> conditions)

Maybe it's the difference between LOAD_CONST and LOAD_GLOBAL. We
can wonder why g uses the latter.

-- 
Neil Cerutti