Performance#

How long Planning Engine takes depends on the shape of the plan and what you ask it to do. Scheduling a dependency chain, previewing an edit to a small part of a project, and leveling heavily contested resources are different workloads.

The measurements below cover all five platforms: native Rust, WebAssembly (WASM), JavaScript (JS), .NET, and Java. All times are in milliseconds, shown as medians rounded to three decimal places. They come from one set of saved benchmark runs. They aren't latency guarantees for every project or device.

For every benchmark case and the complete set of measurements, see the full performance report.

Scheduling a complete plan#

When you open a project or rebuild its schedule after a major change, the engine has to place the whole plan. The work might be one long delivery chain, lots of parallel activities, or separate groups of linked tasks.

Growing the chain from 1,000 to 10,000 tasks raises scheduling time from 1.7 to 13.6 ms in Rust and from 2.6 to 22.3 ms in WASM. On these workloads, time grows roughly in proportion to size.

Backward scheduling#

Backward scheduling works back from a deadline to the latest dates each task can take. In these runs, the deadline falls before every stored start, so every task in the chain has to move.

Planning backward costs about the same as planning forward over a chain of the same size.

Summaries and hierarchy#

A dependency between two phases can be cheap or expensive depending on how the engine schedules the group. Each workload below links one 1,000-task summary to another with a single relationship.

With preservation and group movement enabled, the successor phase shifts as one block, and the whole case takes about 1.8 ms in Rust. With group movement disabled, or when you compress, the one summary relationship expands into a relationship between every pair of children, a million in this case. Then the same 2,002 tasks take 30 to 37 ms in Rust, more than the 10,000-task chain. So dependency structure matters as much as the visible task count.

Working-time calendars#

These plans have 2,000 independent tasks, each 1,000 working units long. Only the duration unit changes.

With no dependencies to propagate, the time goes into walking each task's working time. How fast a platform does that depends on the unit: JS is the slowest platform on day durations and the fastest on hour durations.

Rejecting a cycle#

When dependencies form a loop, scheduling aborts without moving dates and reports the tasks and links involved. These chains start with a two-task loop.

Editing an existing plan#

When a user changes a task's duration or previews a drag, the app needs the consequences fast. In these runs, the edit affects a 10-task dependency chain inside a larger project. The rest of the tasks aren't connected to that chain.

At 10,000 tasks, applying and scheduling the edit takes about 0.7 ms in Rust and 1.1 ms in WASM. An isolated preview takes about 1.3 and 1.7 ms.

Keeping the project loaded makes these local interactions much cheaper than scheduling it again. In WASM, sending the whole edited plan through the stateless schedule call takes 7.0 ms at 10,000 tasks, about 6.5× the cost of applying the edit to a loaded project. Restricting the scheduling scope cuts the Rust edit time by another 28% here, and the .NET time by 19%.

Resource leveling#

Say a team has more work scheduled at once than its people can handle. Leveling moves or pauses tasks to remove the overload, then updates dependent work. Independent jobs are easier to rearrange than linked delivery stages, especially when people have different working calendars.

With independent jobs and the same modest overload pattern, ten times more tasks raises time from 3.9 to 38.5 ms in Rust and from 6.0 to 50.7 ms in WASM.

The linked 5,000-task plan is slower than the independent 10,000-task plan. Moving work there also affects successors and shared assignments. Differing resource calendars push the Rust time from 52.7 to 80.0 ms, about 52% more, and the WASM time from 72.8 to 103.9 ms. All these plans finish leveling with no overload windows left, with the same number of delayed tasks on every platform.

Comparing alternative assignments#

A planner wants to relieve an overloaded person and compare where their work could go. The engine can evaluate several assignment alternatives against the same plan and show how each one affects finish dates and overload before anything is accepted. Here it compares nine alternatives across a team of 32 resources. Each alternative is either scheduled on its own or also leveled to account for contention.

Scheduling nine alternatives for 5,000 tasks takes about 38.7 ms in Rust and 44.0 ms in WASM. Add leveling and that rises to 150.4 and 174.2 ms, since each alternative also has to resolve its resource contention. These times cover the whole set of alternatives, not a single one. Every platform produces the same candidate scores and the same preferred alternative.

Rust, .NET, and Java can evaluate candidates concurrently using worker threads. With nine workers, the 5,000-task schedule-and-level comparison drops from 150.4 to 32.0 ms in Rust, about 4.7× faster. Java goes from 327.4 to 61.6 ms (5.3×), and .NET from 307.8 to 149.5 ms (2.1×). The candidate scores and preferred result stay the same. That makes more thorough comparisons practical without changing the planning policy. The gain depends on available cores and the workload, and concurrent candidates need more memory. WASM and JS evaluate candidates one at a time.

Choosing a leveling placement strategy#

When a small team is heavily booked across several dependent workstreams, finding a spot for one reassigned task can take many adjustments. This example compares five assignment alternatives across three linked chains: 375 work tasks, three summaries, four resources, and 594 assignments.

The engine offers two placement strategies. Minimal steps reconsiders which task should move as it resolves each overloaded time bucket, which allows finer placement decisions. Skipping contended regions moves work past a longer busy stretch all at once. It's faster here, but it gives up intermediate choices and can produce a slightly worse placement for an individual alternative.

Skipping cuts the Rust comparison time from about 328 to 140 ms, a 2.3× speedup. The other platforms gain 2.2× to 2.4×. Unlike worker-based parallel evaluation, though, it changes the resulting plans and can change which assignment is preferred.

The quality tradeoff isn't uniform. In these saved results, two alternatives get slightly worse with skipping: their scores rise from 103 to 105 (lower is better). The other three improve, and the best available score drops from 101 to 86. So the faster strategy gives different placement quality. That doesn't mean the slower strategy always produces the better plan.

Suggesting assignments#

Assignment suggestions fill open slots with eligible people and score each choice by its effect on the plan. Here the engine fills 20 empty slots, scoring 5 candidates for each, on the same 32-resource projects used for comparing alternatives. Suggestions schedule each candidate without leveling.

Filling all 20 slots scores 100 candidates in total, so at 5,000 tasks each candidate costs about 8 ms in Rust. The five platforms stay close to one another on this workload. The 5,000-task rows were measured only once or twice each.

Measurement environment#

All five reports were saved on macOS, ARM64, and each workload takes the median of 5 measured repetitions.

Treat the columns as reference measurements, not a controlled comparison of platforms.

Full-plan timings include input handling, scheduling, and result production. Leveling and evaluation timings include initial loading and scheduling. Edit timings start from a project that's already solved. Startup, WASM initialization, and UI rendering aren't included. Rust, JS, .NET, and Java time one complete JSON API call, from decoding the input to encoding the response. WASM times the calls a JavaScript caller makes: for full plans, serializing the input, the schedule call, and parsing its result; for leveling and evaluation, creating the project, solving, and the leveling or evaluation call itself. Cloning and final disposal fall outside its leveling intervals. A dash means the platform has no measurement for that case.