One line in vx.workspace.ts picks which ready task starts first when there are no timings yet. The default is unchanged, and a history plugin still leads.
Performance
Performance
When more tasks are ready than workers, something picks which one
starts. Without timings every rule is a guess, and
each guess loses some graph. Now you pick
the guess:
vx.workspace.ts
exportdefault {
schedule: 'critical-path',
}
schedule
Starts first
most-work (default)
The task the most work waits on, at any depth
critical-path
The task at the head of the longest chain of tasks
A schedule plugin such as
@vzn/vx-schedule-history ranks
tasks by recorded time. Its ranking still comes first under every
strategy. The strategy only breaks its ties, and decides the order for
tasks the plugin has no timing for yet.
Keep the default unless you know your graph. If a slow task with
nothing after it (a typecheck, a lint) keeps starting late, try
ready-order or add the history plugin. If long chains of small tasks
finish last, try critical-path. Once the history plugin has a run to
learn from, it picks a better order than any of these.
When more tasks are ready than workers, a runner has to pick. Five rules for picking, the graphs where each one wins and loses, measured with vx, and why recorded timings beat every rule that has to guess.
Performance
How many tasks at once? Count the cores you are given
Inside a container, the CPU count a program sees is the host’s. A task runner that trusts it starts more work than the kernel will run. Here is how vx picks its worker count.