Performance Overhead in Ternary Operator Due to Value Loading vs Constant Loading

[ashm-dev]

Bug report

Bug description:

A performance bottleneck has been identified in CPython's bytecode generation for ternary expressions compared to traditional if-else statements, specifically related to how constants are loaded.

Bytecode Comparison

Traditional If-Else (Optimized)

def test(var):
    if var:
        return True
    else:
        return False

Bytecode:

  8           0 RESUME                   0

  9           2 LOAD_FAST                0 (var)
              4 POP_JUMP_IF_FALSE        1 (to 8)

 10           6 RETURN_CONST             1 (True)

 12     >>    8 RETURN_CONST             2 (False)

Ternary Operator (Less Efficient)

def test2(var):
    return True if var else False

Bytecode:

 14           0 RESUME                   0

 15           2 LOAD_FAST                0 (var)
              4 POP_JUMP_IF_FALSE        2 (to 10)
              6 LOAD_CONST               1 (True)
              8 RETURN_VALUE
        >>   10 LOAD_CONST               2 (False)
             12 RETURN_VALUE

Problem
In the ternary operator version:

• LOAD_CONST is used instead of the more efficient RETURN_CONST
• This results in an additional RETURN_VALUE instruction
• Leads to slightly increased bytecode complexity and potential performance overhead

Recommendation
Modify the bytecode generation for ternary expressions to:

• Use RETURN_CONST when returning boolean constants
• Minimize additional instructions
• Align bytecode generation with the efficiency of traditional if-else statements

Additional Notes

• This is a micro-optimization
• Impact may vary across different Python versions
• Primarily of interest to performance-critical code paths

CPython versions tested on:

3.12

Operating systems tested on:

Linux

[picnixz]

cc @markshannon

[picnixz]

Question: is this the result with a DEBUG build? or PGO build?

[ashm-dev]

@picnixz This is not a special build, but just python3. 12 from uv. Python version -- 3.12.7

[sobolevn]

I think that this is a known problem (but I cannot find the needed issue).

[Eclips4]

Question: is this the result with a DEBUG build? or PGO build?

PGO/LTO/BOLT/Debug builds doesn't affect the actual bytecode construction.

There's no more a RETURN_CONST opcode, so I don't think this is an issue, and this in fact is a duplicate of #121246.
Nevertheless, thank you for the report, Shamil.

[Eclips4]

FYI, here's the bytecode of test and test2 functions on 3.14 branch, which in fact are identical:

eclips4@nixos ~/p/p/cpython (remove-ast-optimizer)> ./python
Python 3.14.0a2+ (heads/remove-ast-optimizer-dirty:7ce21584115, Jan  1 1980, 00:00:00) [GCC 13.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> def test(var):
...     if var:
...         return True
...     else:
...         return False
...
>>> dis.dis(test)
  1           RESUME                   0

  2           LOAD_FAST                0 (var)
              TO_BOOL
              POP_JUMP_IF_FALSE        2 (to L1)

  3           LOAD_CONST               0 (True)
              RETURN_VALUE

  5   L1:     LOAD_CONST               1 (False)
              RETURN_VALUE
>>> def test2(var):
...     return True if var else False
...
>>> dis.dis(test2)
  1           RESUME                   0

  2           LOAD_FAST                0 (var)
              TO_BOOL
              POP_JUMP_IF_FALSE        2 (to L1)
              LOAD_CONST               0 (True)
              RETURN_VALUE
      L1:     LOAD_CONST               1 (False)
              RETURN_VALUE
>>>