Parcel: High CPU Usage at idle (after build finished, not changing files)

[uglycoyote]

🐛 bug report

Parcel using most of CPU even when at idle.

🎛 Configuration (.babelrc, package.json, cli command)

dependencies from my package.json:

  "dependencies": {
    "@blueprintjs/core": "^3.8.0",
    "@blueprintjs/icons": "^3.3.0",
    "@blueprintjs/select": "^3.4.0",
    "@types/dat.gui": "^0.7.2",
    "@types/moment": "^2.13.0",
    "@types/react": "^16.7.6",
    "@types/react-dom": "^16.0.9",
    "@types/react-router-dom": "^4.3.1",
    "@types/three": "^0.93.13",
    "dat.gui": "^0.7.3",
    "dotenv": "^6.2.0",
    "moment": "^2.22.2",
    "prando": "^5.0.0",
    "react": "^16.6.3",
    "react-dom": "^16.6.3",
    "react-router": "^4.3.1",
    "react-router-dom": "^4.3.1",
    "three": "^0.99.0",
    "three-obj-loader": "^1.1.3"
  },
  "devDependencies": {
    "@types/enzyme": "^3.1.15",
    "@types/enzyme-adapter-react-16": "^1.0.3",
    "@types/jest": "^23.3.10",
    "@types/jsdom": "^12.2.0",
    "@types/react-test-renderer": "^16.0.3",
    "cssnano": "^4.1.7",
    "enzyme": "^3.7.0",
    "enzyme-adapter-react-16": "^1.7.0",
    "identity-obj-proxy": "^3.0.0",
    "jest": "^23.6.0",
    "jsdom": "^13.0.0",
    "less": "^3.8.1",
    "react-test-renderer": "^16.6.3",
    "ts-jest": "^23.10.5",
    "typescript": "^3.1.6"
  }

🤔 Expected Behavior

Parcel should use zero CPU when doing nothing. Parcel should do nothing, or nearly nothing, when it has been a long time since it finished building and a long time since i have changed any files in the project directory.

😯 Current Behavior

Parcel's node process sits at 200% or more CPU in Activity Monitor on top on my MacBook, even though it says "Built in (num seconds)" as the output. It is not clear what it is working so hard doing.

🔦 Context

This problem is not occurring for me on a brand new empty Typescript/React project created referencing this short tutorial

However in my real project, I have a fair number of dependencies, and it's not clear if any of these are what causes Parcel to start using so much CPU resources.

In the project directory that has the problem, I tried commenting out the entire contents of my index.tsx and replacing it with a dummy rendering function like that in the tutorial link above, however it still behaves badly.

I tried cloning my project into a new directory, it still had same issue.

I tried cloning my project into a new directory, then deleting the contents of the entry-point tsx file except for some dummy "hello world stuff" and deleting package.json, to the point where it was effectively the same as the "hello world" project built from scratch, the Parcel behaved better. I then gradually re-adding dependencies. It seemed like each time I adedd more dependencies the bad behavior gradually increased (it used more and more CPU at idle), which gave me the impression that there was not one specific dependency that was causing the problem, maybe it's just an issue that grows with the amount of dependencies.

Parcel still has great performance in terms of turnaround and seeing the new changes in the browser quickly, but with this kind of CPU usage during what one would expect to be an idle period, it becomes impractical to use my laptop unplugged without battery concerns, or on my actual lap, without testicular warming concerns.

I searched the other issues on GitHub for "CPU" and "Performance" and mostly found people complaining about high CPU usage accompanied by a "hang" but in my case it seems not to be hung, it is responsive, just cooking the CPU too much when there should be nothing much to do.

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.10.3
| Node | 11.3.0
| npm/Yarn | npm 6.4.1
| Operating System | Mac OS Mojave

[DeMoorJasper]

should use nothing is probably impossible due to the overhead of all the node processes parcel spawns and the watcher, although 200% is not normal.

Any minimal repro you could share? I've never experienced this myself

Most high cpu/hanging issue were related to node-sass in the past, which got replaced with sass recently

You could try running parcel with --log-level 4 to see a verbose log of what parcel is doing. This might reveal something that the status didn't. Unfortunately it probably won't

[uglycoyote]

You are correct, --log-level 4 does not reveal anything. It spits out a lot more information, but nothing after the "Built in (num seconds)" message that concludes the build, and therefore no insight as to what is causing high CPU usage after that time.

As another piece of information, I have synced the same repo under Windows 10, and Parcel uses negligible CPU after the build finishes, so for whatever reason the problem seems specific to my OSX environment.

I will try to isolate a minimum reproducible version of the problem soon.

Is there a way to run Parcel under a profiler to see a flame graph of what's going on? I'm not sure what options exist for profiling Node applications. From my initial googling on this topic it seemed like most of the available options required some kind of intrusive insertion of profiling code inside of the project.

[DeMoorJasper]

You can use --inspect-brk to start up an inspector agent for a node application.

Perhaps this article is helpful as it explains it in more detail than I could possibly go in this reply https://medium.com/@paul_irish/debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27

[uglycoyote]

This CPU usage issue seems to have gone away with updating parcel, I did npm install -g parcel-bundler@latest and went from 1.10.3 to 1.11.0 and now I cannot repro the high CPU usage issue at idle. Was there a fix for anything like this lately?

You mentioned the SASS-related change, but I was seeing CPU usage on project which were not using SASS.

I did try profiling using Chrome before upgrading with the --inspect-brk option, but was only able to get a profile with a single node in the tree that said (program) so didn't get any useful information out of it.

Anyhow, since it's not happening with the latest, I guess this issue can be closed out.

[DeMoorJasper]

@uglycoyote there have been a lot of bugfixes. So it possibly fixed it

[tiborsaas-tw]

Can confirm, upgrading from 1.10.3 to 1.11.0 solved the issue on High Sierra.