CPU-based Dynamic Parallel Execution

[HaasStefan]

Currently, the PR #232, implementing a concurrency flag to run tasks in parallel has a fixed upper bound for tasks running in parallel. This is also how other JS-focused monorepo tools such as Nx and Turborepo are doing it, but this could be optimized based on CPU and RAM usage.

Especially large monolithic monorepos often have hundreds of small libraries with fast running targets, but a few really large app targets, which eat most of the memory and CPU. Such repos would benefit from dynamic parallelism based on memory and cpu usage, such that it can have a high level of parallelism for small tasks, and can reduce the parallelism for resource intensive targets. This maximizes parallelism without running risk of OOM issues.

Technically this could be achieved by implementing a task queue and a resource watcher that guards pulling from the queue based on resource usage.

For example see:
BuildXL Flags - MaxRamUtilizationPercentage

[branchseer]

That's smart, but will take extra efforts. I propose we do this gradually:

1. Implement fixed upper bound (unblocks parallel dev server tasks)
2. Add a per-task config (something like exclusiveRun), to indicate this task always takes up all cpu cores so it won't be executed in parallel with others. Its value defaults to true for vp build/lint/fmt/etc tasks.
3. Look into the more intelligent ways as you suggest.

[HaasStefan]

2. Add a per-task config (something like exclusiveRun), to indicate this task always takes up all cpu cores so it won't be executed in parallel with others. Its value defaults to true for vp build/lint/fmt/etc tasks.

I would not make it user defined. I would actually make it based on past runs and use a local or remote db to store metadata for runs and the resource usage. But yea, I would also just keep this in some backlog when we got time in the future. But we should make sure the PR #232 lets us be flexible about this in the future such that such a feature would not have breaking changes.

[branchseer]

👍 I agree we should not make exclusiveRun exposed as user config field. But I still want this to be a pre-run knowledge for vite+ first party subcommands, so the performance won't hurt in the first run or when cache is completely off.

As long as we don't add user config field, we shouldn't worry about breaking changes. (We don't promise whether tasks are paralleled or not.)

BTW PR #232 is abandoned: it does too many things. I'll instead create a stack of PRs for parallel execution.