Repository navigation
free-threading one line comprehension is significantly slower than multi line #159493
Description
Bug report
import sys
import time
from concurrent.futures import ThreadPoolExecutor
if sys._is_gil_enabled():
sys.exit("the GIL is enabled: run this with a free-threaded build (python3.Xt)")
# slow
def tag_fused(vocab, batch):
return [vocab.get(tok, "unk") for tok in batch]
# fast
def tag_unfused(vocab, batch):
return [vocab.get(tok, "unk")
for tok in batch]
def seconds(tag, vocab, batch, nthreads, nbatches=600):
with ThreadPoolExecutor(nthreads) as pool:
t0 = time.perf_counter()
for a in pool.map(tag, [vocab] * nbatches, [batch] * nbatches):
pass
return time.perf_counter() - t0
def main():
tokens = [sys.intern(f"tok{i}") for i in range(20000)] * 10
vocab = {tok: ("noun", "verb", "adj")[i % 3] for i, tok in enumerate(tokens)}
for tag in (tag_fused, tag_unfused):
t1 = seconds(tag, vocab, tokens, 1)
t6 = seconds(tag, vocab, tokens, 6)
print(f"{tag.__name__:11s} 1 thread {t1:.3f}s 6 threads {t6:.3f}s "
f"speedup {t1 / t6:.1f}x")
main()python3.15t Tools/ftlockbench/repro_store_fast_load_fast_borrow.py
tag_fused 1 thread 2.624s 6 threads 12.444s speedup 0.2x
tag_unfused 1 thread 2.549s 6 threads 0.596s speedup 4.3x
With identical functions apart from the multi line list comprehension that does a load and store specialisation the multi line breaks the optimisations to STORE_FAST_LOAD_FAST resulting in a severe slowdown in free threading python.
If we disassemble the unfused case no
for tag in (tag_fused, tag_unfused):
load = next(i for i in dis.get_instructions(tag) if "vocab" in i.argrepr)
print(f"{tag.__name__:11s} loads vocab with {load.opname} ({load.argrepr})")
This is due to the different emited op codes.
tag_fused loads vocab with STORE_FAST_LOAD_FAST (tok, vocab)
tag_unfused loads vocab with LOAD_FAST_BORROW (vocab)
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Activity
picnixz commentedon Oct 15, 2026
That's... surprsing. The opcodes are also different even on default build (at least on
Python 3.14.7 (main, Aug 5 2026, 10:29:49) [Clang 21.0.0 (clang-2100.1.1.101)])eendebakpt commentedon Oct 16, 2026
A smaller reproducer:
A potential solution is to make the
STORE_FAST_LOAD_FASThave a borrowed version as well. We can also check the opcode statistics (an older set of statistics bm-20250719-3.15.0a0-800d37f shows theSTORE_FAST_LOAD_FASTis not very common) whether we still need theSTORE_FAST_LOAD_FAST.The reason the two cases are handled differently is in
make_super_instructionfrom in #105230. @markshannoneendebakpt commentedon Oct 16, 2026
In all cases where
STORE_FAST_LOAD_FASTis used we can use aSTORE_FAST_LOAD_FAST_BORROW. To not increase the number of opcodes we can therefore replaceSTORE_FAST_LOAD_FASTwithSTORE_FAST_LOAD_FAST_BORROW. Allowing super instructions over multiple lines does not seem to happen often and making that work might lead to some tricky situations, so am leaving that idea for now.A prototype PR is: main...eendebakpt:cpython:store-fast-load-fast-borrow
All code objects from compiling the 2042 files of
Lib/(counts of instructions,CACHEentries excluded):STORE_FAST_LOAD_FASTSTORE_FAST_LOAD_FAST_BORROWLOAD_FAST_BORROW_LOAD_FAST_BORROWLOAD_FAST(strong)LOAD_FAST_BORROWThe number of
STORE_FAST_LOAD_FAST/STORE_FAST_LOAD_FAST_BORROWis not identical because the optimization is at different place, so other super instructions might get priority. Nevertheless, the bulk of theSTORE_FAST_LOAD_FASTis converted to the borrow type. This resolves the issue here (refcount contention), but also improve single-threaded performance[vocab.get(tok, "unk") for tok in batch](one line)for x in it: a.append(x)(one line)for x in it: n = n + 1[i*2 for i in ints], 10,000 ints[2*i for i in ints](no store/load pair, control)Note: removing the bug label. The code works (slower, but still works), so no backports are needed imo.
picnixz commentedon Oct 16, 2026
I still think it's a bug somehow because newlines should not result in a change of bytecode IMO. And the fact that it's significantly slower is annoying. But we don't need to backport it (but I still think it's a bug)
johng commentedon Oct 17, 2026
Agree with the above that newlines or anything which doesn't change the actual representation of the program should not impact the bytecode. Should the fix focus on why there is a divergence there?
kumaraditya303 commentedon Oct 21, 2026
I think this is a compiler bug somewhere, I'll work on fixing this.