Why do you ask? Do you have an interest in it? Pants related or otherwise?

I fairly regularly hit hurdles at my day job where I legitimately wonder if Pants is the right tool for us. The perf stuff hurts, and I wish I had more time to devote to fixing it. I think there's a lot of finger-crossing here that removing GIL will fix these problems (which I understand)

But I do wonder how much gain you'd get starting there, since there'd still a lot of switching back and forth between python and rust. Anecdotally, I see a lot of low CPU usage but high-ish load when doing this.

And this user is also having issues with performance of graph stuff: https://pantsbuild.slack.com/archives/C046T6T9U/p1689589616273189

Although that case seems pathological for other reasons

given that the longest running task descriptions are "Resolve transitive targets", which is a single rule (with a ton of dependencies) in

graph.py

I took a whack at sampling stack frames with https://bloomberg.github.io/pystack/ with the hope that I might catch some condition that points me in the right direction, but it's hard to make it catch anything in particular. I probably need to figure how to run Pants in a debugger on my repo if I want to be able to set breakpoint conditions and look for issues

I also saw something surprising... I expected the GIL to leave multiple stacks going (but only one executing with the GIL at a time), but I only see one rule thread per capture with a stack. There are 1-2 other threads including the main thread that launches the scheduler, and sometimes a streaming workunit handler thread waiting on a lock

And... what's more, altering the number of rule threads has essentially zero impact on performance for me. Anything from 2 to 12 executes in roughly the same time, and with the same amount of memory.