mix format slower when using MIX_OS_DEPS_COMPILE_PARTITION_COUNT

[spicychickensauce]

Elixir and Erlang/OTP versions

Erlang/OTP 28 [erts-16.1] [source] [64-bit] [smp:16:16] [ds:16:16:10] [async-threads:1] [jit:ns]

Elixir 1.19.0 (compiled with Erlang/OTP 28)

Operating system

Arch Linux

Current behavior

Running mix format once with MIX_OS_DEPS_COMPILE_PARTITION_COUNT=8 and once without shows that with it, the formatting is about 4x slower:

$ time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=0 mix format

real    0m0.583s
user    0m2.497s
sys     0m0.342s

$ time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=8 mix format
mix deps.compile running across 8 OS processes

real    0m2.145s
user    0m2.535s
sys     0m0.342s

Expected behavior

It should be at least the same speed

[spicychickensauce]

Sorry, might have been a bit too early reporting that one.
Doing the same on a different project doesn't show the issue:

$ time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=0 mix format

real    0m0.669s
user    0m3.491s
sys     0m0.407s

$ time MIX_OS_DEPS_COMPILE_PARTITION_COUNT=8 mix format

real    0m0.538s
user    0m2.438s
sys     0m0.320s

But it is consistent on the other project.

Also, it always prints this additional line mix deps.compile running across 8 OS processes, not sure what's causing that, since there is nothing to compile

[josevalim]

Does the slow project have path dependencies? That may explain it.

[spicychickensauce]

Does the slow project have path dependencies? That may explain it.

Yes, it does, great guess!
I'm doing some vendoring of abandoned libraries there: {:thingy, path: "./vendor/thingy"}

[spicychickensauce]

Wow, that was fast 👏