>
> I guess this is true in a technical sense, but is it true in a noticeable
> sense? Yes, having lots of processes vying for a lock isn't great, but I'd
> be surprised if it adds up to very much. Am I wrong about this?
Running the tests serially in a single process doesn't have the setup cost
> you will degrade to *worse than single process* speed.
I guess this is true in a technical sense, but is it true in a noticeable
sense? Yes, having lots of processes vying for a lock isn't great, but I'd
be surprised if it adds up to very much. Am I wrong about this?
> This would silently
> 1. Should we tweak the docs to show something like the above, that would
> make the solution there easier to just drop in?
>
I don't think so. Locking is a last resort and ruins performance - if used
across your whole test suite you will degrade to *worse than single
process* speed. You should
I spent the day today making the tests for my project run in parallel. As
part of that, I had my first encounter with the SerializeMixin, which you
can use in conjunction with the `--parallel` flag to ensure that certain
tests don't run at the same time. It's neat, in theory:
