Windows: processes started by DCP are throttled by EcoQoS on hybrid CPUs — `AddJavaScriptApp` dev builds run ~2–3× slower than from a terminal

Open
  • Is something wrong?
#21,889 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
csharp, javascript, node.js
Domain
backend, devtools

Research direction

Start by tracing how DCP launches processes for AddJavaScriptApp and how child processes are handled on Windows; the issue does not name source files or tests. Reproduce the reported build-time difference on Windows 11 with a hybrid CPU in Balanced mode, then check whether disabling execution-speed throttling for the launched process and its children removes the slowdown. Done means the behavior is addressed for local runs or a per-resource option is provided, with a regression test or documented verification.

Written by the indexing model from the issue text.

Description

area-app-model
Is there an existing issue for this?
  • I have searched the existing issues
Describe the bug

On Windows 11 with a hybrid CPU (P + E cores), JavaScript dev servers started through AddJavaScriptApp build 2–3× slower than the same npm run start in a terminal. The cause is Windows power throttling (EcoQoS): the process DCP starts has no visible window, so Windows classifies it as background work and, under the default Balanced power mode, schedules it on efficiency cores at reduced clock.

Same Angular 15 (webpack) app, same config, warm build cache; the number is the builder's reported Time: for the initial build.

How the dev server was started Initial build
npm run start in a terminal 32–48 s
Same, with EcoQoS forced on the node processes via SetProcessInformation(ProcessPowerThrottling) 102 s
AddJavaScriptApp(...) under the AppHost, Power mode = Balanced 84–85 s (two runs)
AddJavaScriptApp(...) under the AppHost, Power mode = Best performance 31 s
AddJavaScriptApp(...) under the AppHost, Balanced, AppHost opts node.exe out of throttling (workaround below) ~31 s

A second app (Angular 21, esbuild) shows the same pattern: ~9 s from a terminal, ~20 s under the AppHost.

Running the two frontends concurrently from terminals costs only ~4 s, so CPU contention with the other resources does not explain the gap.

Expected Behavior

Processes started by the AppHost for local development run at the same speed as when started from a terminal.

Steps To Reproduce
  1. Windows 11 on a hybrid CPU, Power mode = Balanced (the default).
  2. AppHost with a CPU-heavy JavaScript dev server, e.g.: 
    builder.AddJavaScriptApp("web", "../web", "start")
    .WithHttpEndpoint(targetPort: 4200, isProxied: false)
    .WithNpm(install: false);
    where start runs ng serve (or any webpack/esbuild dev build).
  3. Note the initial build time in the resource's console logs.
  4. Stop the AppHost and run npm run start from a terminal in the same folder: the build is 2–3× faster.
  5. Optionally: switch Power mode to Best performance and start the AppHost again — the gap disappears.
Exceptions (if any)

No response

Aspire doctor output
Anything else?
Workaround

A hosted service in the AppHost that opts node.exe processes out of execution-speed throttling (no admin rights needed for processes of the same user):

// ControlMask = PROCESS_POWER_THROTTLING_EXECUTION_SPEED, StateMask = 0 → throttling off
var state = new PROCESS_POWER_THROTTLING_STATE { Version = 1, ControlMask = 0x1, StateMask = 0 };
SetProcessInformation(OpenProcess(PROCESS_SET_INFORMATION, false, pid), ProcessPowerThrottling, ref state, (uint)Marshal.SizeOf(state));

It polls every 2 s and applies this to each new node.exe. We apply it to the node processes themselves (npm → cmd → node), not only the process DCP starts directly.

Suggested fix

DCP opts the executables it starts — and ideally their child processes — out of power throttling on Windows, at least for local runs. Alternatively, offer a per-resource option for it. Other projects that hit the same EcoQoS heuristic with windowless child processes fixed it the same way (e.g. Stockfish PR #7255).

Environment
  • Aspire.AppHost.Sdk 13.6.1, Aspire.Hosting.JavaScript 13.6.1
  • Windows 11 Pro 10.0.26300, Intel Core Ultra 9 285H (6 P + 8 E + 2 LP-E cores)
  • Node 22.19.0; Angular CLI 15.1.5 (webpack 5.75) and Angular 21.2 (@angular/build esbuild)
  • AppHost started without a debugger
Dominant language
C#
Stars
6.4k
Forks
1k
Avg merge
3d 3h
Merged PRs (30d)
349

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/aspire

All issues in microsoft/aspire

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.