Optionally use threads instead of processes?

[Astlaan]

Hi,

For me, cargo nextest run is running slower than cargo test.

For example, in one of the crates I'm working on, cargo test takes 1m25s, while cargo nextest run takes 2min7s.

I suppose this has to do with the fact that many of my test functions have an expensive initialization. I had therefore created a lazy_static, so that the expensive code is not being repeatedly run, but the problem is that, since nextest uses processes and not threads, this lazy_static has to be constantly recalculated. Maybe also in cases of high number of tests there ends up being extra overhead in creating/initializing processes than threads? Or is there anything else that could be causing this?

In terms of speed, I prefer to stick with the cargo test and its thread model. However, the output of cargo nextest is much nicer, of course. Does cargo nextest allow running the tests with the output style of cargo nextest, but with the thread model of cargo test?

Thank you

[sunshowers]

Thanks for the report!

That isn't currently possible (#27), and as documented there would be several weeks of intensive design and implementation work. I'm not planning to do this for an indefinite time period, though I'm certainly open to you or someone else adding that feature.

For specific use cases, it may be possible to use one of nextest's other features to help. For example, if you can serialize your state in a setup script, you can then deserialize it in your tests. That's similar to what we do at work (though in our case, we use the setup script to configure a database with all the tables, but no data in them.) Whether this works for you probably depends on the specifics.

Going to close this as a dup of #27 -- happy to continue the conversation there!