freelist feature causes slowdowns universally

[Zaczero]

Bug Description

I've been naively enabling freelist to enhance performance of my applications. Turns out there's not a single case it helped the performance. Turns out the change #4902 caused a bottleneck that completely waives any benefits of using freelist - it's better to remove the feature altogether.

I digged deeper.

Fable 5 conclusion was: Short answer: because since PyO3 0.23.5 (Feb 2025), every freelist push and pop takes a std::sync::Mutex — on all builds, including GIL builds — and the locking overhead now exceeds what the freelist ever saved. I reproduced your observation in the container with a controlled experiment; the sign genuinely flipped.

Which makes sense to me and I think this observation is good.

Steps to Reproduce

1. Use freelist
2. Measure

Backtrace

Your operating system and version

Linux 6.18

Your Python version (python --version)

Python 3.14

Your Rust version (rustc --version)

rustc 1.96.0 (ac68faa20 2026-05-25)

Your PyO3 version

0.28.3

How did you install python? Did you use a virtualenv?

uv

Additional Info

Before Fable was restricted, I managed to ideate some ideas on potential ways forward: https://claude.ai/share/c18f23ad-b07e-4ffe-a285-bd40e92b81dd Do whatever you want with that information.

[Zaczero]

I may be able to contribute a PR given I already have solid testing grounds and if there's no better person to handle that.

[alex]

Pretty sure we should just go with a lock-free intrusive linked list here. All that is necessary for evil to succeed is for good people to do nothing.

…

On Sat, Jun 13, 2026, 10:08 AM Kamil Monicz ***@***.***> wrote: *Zaczero* left a comment (PyO3/pyo3#6133) <#6133 (comment)> I may be able to contribute a PR given I already have solid testing grounds and if there's no better person to handle that. — Reply to this email directly, view it on GitHub <#6133?email_source=notifications&email_token=AAAAGBE6I562YZS6IK4K3UT47WDBVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHEZDANJZG4YKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#issuecomment-4699205970>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBHI5532U6JQEGSZGY347WDBVAVCNFSNUABEKJSXA33TNF2G64TZHM4TCMJVGE2DIMR3JFZXG5LFHM2DMNJWGI3DMNZXHGQXMAQ> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AAAAGBA3IQXAILSKAOPNZ7347WDBVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHEZDANJZG4YKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSVGM33PORSXEX3JN5ZQ> and Android <https://github.com/notifications/mobile/android/AAAAGBCDW5L2YFM7Z6EHNID47WDBVA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINRZHEZDANJZG4YKM4TFMFZW63VKON2WE43DOJUWEZLEUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>. Download it today! You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[mejrs]

I'm also tempted to just remove the freelist option. Is it really worth using?

[Zaczero]

Without the Mutex, in high allocation churn benchmarks, it shows about 10% performance improvement. So there are wins to freelist if executed correctly. Removing the Mutex is a free option (at a cost of code verbosity) for Python GIL builds (that are still the majority and don't require the Mutex).