Repository navigation
Potential performance regression with Python 3.14 bench_mp_pool on Linux #139881
Closed as not planned
Description
Bug report
Bug description:
Hi team, I was running pyperformance and found that the bench_mp_pool in 3.14 was way more slower than in 3.13.
I uses pyperformance-1.11.0 installed from master branch and conda-forge Python builds, the system is Ubuntu 22.04.
+-------------------+-----------------------------+-----------------------------+ | Benchmark | Python 3.13.7 | Python 3.14.0 | +===================+=============================+=============================+ | bench_mp_pool | 6.08 ms | 1.91 sec: 315.05x slower | +-------------------+-----------------------------+-----------------------------+
I also tried it on another Ubuntu 22.04 box, it was better but still tens of times slower,
+-------------------+-----------------------------+-----------------------------+ | Benchmark | Python 3.13.7 | pPython 3.14.0 | +===================+=============================+=============================+ | bench_mp_pool | 13.4 ms | 367 ms: 27.42x slower | +-------------------+-----------------------------+-----------------------------+
CPython versions tested on:
3.14
Operating systems tested on:
Linux
Activity
LamentXU123 commented on Oct 10, 2025
picnixz commented on Oct 10, 2025
Maybe it's because we are changing the default start method? we switched from fork to forkserver on Linux in Python 3.14. Could you try to alter the benchmark and explicitly call multiprocessing.set_start_method("fork") to see what happens? (I don't know where you should put that call though...)
@LamentXU123 That's not a comparison between 3.14 and 3.13.
NoAnyLove commented on Oct 11, 2025
@picnixz I think you're right, 3.14 matches 3.13 after adding multiprocessing.set_start_method("fork").
btw, I'm running benchmarks on a small Ubuntu VM with a few cores, 3.14 is only a few times slower than 3.13.
Without multiprocessing.set_start_method("fork"),
With multiprocessing.set_start_method("fork"),
thesamesam commented on Oct 12, 2025
Two issues w/ forkserver, but it may be distinct from these:
picnixz commented on Oct 12, 2025
@gpshead Was such slowdown actually planned or is it a legitimate issue somewhere?
eendebakpt commented on Oct 27, 2025
The PR introducing the slowdown is #101556. But according to the python speed center python 3.15 will have a speedup again:
chris-eibl commented on Oct 30, 2025
Yeah, that's basically what @LamentXU123 has posted above #139881 (comment), but it got hidden. Looking what happened around that time in September it must have been #135295 (commit 0912b3a) that cured it. @thesamesam already mentioned the related issue #126631.
#137996 got closed as duplicate of this issue, so most probably this issue here can be closed as duplicate as well?
Since the associated PR got also backported to 3.14 #138607 (commit 64f0e2d) and thus will be part of 3.14.1.
And it was also backported to 3.13 #138609 (commit 9a6137a) and is part of 3.13.8 and 3.13.9. It had less effect on speed there, since, as mentioned above, the default start method on 3.13 is still fork. I am quite confident, that 3.13 without that fix would show worse performance for forkserver as well?
thesamesam commented on Nov 22, 2025
#86354 (pending PR #139537) could have a performance impact as well.
gpshead commented on Nov 22, 2025
The default start method change was intentional and long planned. I don't think it is very useful for that benchmark to focus on the default start method. Explicitly benchmarking each one is a more interesting comparison.
gpshead commented on Nov 22, 2025
anyways I agree that we can close this as (a) it was planned and (b) the bugfix for __main__ preloading being in 3.14.1 happens to make it happier.