Rain

Thanks for the response! As far as OOMing goes, applying backpressure is quite hard here because as you can see in https://github.com/nextest-rs/nextest/blob/421dec9d4da31f41f746172eaded3d09dc184364/nextest-runner/src/runner.rs#L233-L291, we select on both the events coming from...

With the switch to async code and futures, the landscape on this changes quite a bit. We call `buffer_unordered` over here which controls the amount of parallelism: https://github.com/nextest-rs/nextest/blob/c2bd1b6f1b54990de43a9378f12ae6aa04f424ba/nextest-runner/src/runner.rs#L291 We *could*...

Thanks for the report! Based on what you describe my first thought is Gatekeeper or some other sort of macOS process creation bottleneck. It might be worth looking at Activity...

Ahhh I just saw the note about parentalcontrolsd. Yes, sadly, I've seen it be responsible for high CPU usage in other contexts though I've never been able to reproduce it....

Would you be ok making a spindump of parentalcontrolsd and sending it to my email [email protected]? There's an Apple employee that's willing to look: https://twitter.com/Catfish_Man/status/1534577710172778497 Here's how to create a...

Thanks for the minimized test case! I do think this is generally an issue with macOS process execution performance. It could definitely be a custom IT policy that e.g. deployed...

Thank you so much for the investigation @quadruple-output! It does look like an issue with Apple's software at this point. This sort of linear scan through a directory each time...

I've forwarded the report over, thanks! One way nextest can work around this is to do a simplified version of [reusing builds](https://nexte.st/book/reusing-builds): 1. Have a separate option under the `REUSE...

@quadruple-output thanks for waiting! sorry, just got the details: it's rdar://95625035

I'm wondering, could you give it a shot again with cargo-nextest 0.9.43 and macOS Ventura? Nextest now uses `posix_spawn` rather than fork/exec on Mac, which could potentially have made this...