Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: watcher blocks CPU after each rebuild #7490

Open
vkurchatkin-miro opened this issue Aug 7, 2024 · 3 comments
Open

[Bug]: watcher blocks CPU after each rebuild #7490

vkurchatkin-miro opened this issue Aug 7, 2024 · 3 comments
Labels
bug Something isn't working pending triage The issue/PR is currently untouched.

Comments

@vkurchatkin-miro
Copy link

System Info

ystem:
OS: macOS 14.5
CPU: (10) arm64 Apple M1 Pro
Memory: 167.59 MB / 32.00 GB
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.11.0 - ~/.volta/tools/image/node/20.11.0/bin/node
Yarn: 4.1.0 - ~/.volta/tools/image/yarn/1.22.10/bin/yarn
npm: 10.2.4 - ~/.volta/tools/image/node/20.11.0/bin/npm
Browsers:
Chrome: 127.0.6533.99
Safari: 17.5
npmPackages:
@rspack/cli: 1.0.0-beta.1 => 1.0.0-beta.1
@rspack/core: 1.0.0-beta.1 => 1.0.0-beta.1
@rspack/plugin-react-refresh: 1.0.0-beta.1 => 1.0.0-beta.1

Details

In our setup after each interactive rebuild the watcher is restarted and blocks the CPU for ~2 seconds. Subsequently HMR or live reloading is delayed for this amount of time.

It looks like watching is restarted from scratch after every rebuild here:

this.watcher = new Watchpack(options);

while it is not necessary and the watcher instance can be reused (watchpack supports watch to be called again so that it can only create watchers that don't exists).

Reproduce link

No response

Reproduce Steps

N/A

@vkurchatkin-miro vkurchatkin-miro added bug Something isn't working pending triage The issue/PR is currently untouched. labels Aug 7, 2024
@vkurchatkin-miro
Copy link
Author

This fixed the issue for me:

index c78273a3f..906abb084 100644
--- a/packages/rspack/src/node/NodeWatchFileSystem.ts
    b/packages/rspack/src/node/NodeWatchFileSystem.ts
@@ -62,8  62,9 @@ export default class NodeWatchFileSystem implements WatchFileSystem {
                if (typeof callbackUndelayed !== "function" && callbackUndelayed) {
                        throw new Error("Invalid arguments: 'callbackUndelayed'");
                }
-               const oldWatcher = this.watcher;
-               this.watcher = new Watchpack(options);
                if (!this.watcher) {
                        this.watcher =  new Watchpack(options);
                }

                if (callbackUndelayed) {
                        this.watcher.once("change", callbackUndelayed);
@@ -107,9  108,6 @@ export default class NodeWatchFileSystem implements WatchFileSystem {

                this.watcher.watch({ files, directories, missing, startTime });

-               if (oldWatcher) {
-                       oldWatcher.close();
-               }
                return {
                        close: () => {
                                if (this.watcher) {

@hardfist
Copy link
Contributor

hardfist commented Aug 8, 2024

while it is not necessary and the watcher instance can be reused (watchpack supports watch to be called again so that it can only create watchers that don't exists).

I test in webpack and it did recreate watcher every time, but it seems Rspack can reuse the old watcher since we use patch algorithm which is different than webpack now

@hardfist
Copy link
Contributor

hardfist commented Aug 8, 2024

@vkurchatkin-miro it seems create watcher itself shouldn't cost too much but new watcher need to rewatch the old files that will cost time, can you help check whether the 1-2s is spent on

@vkurchatkin-miro can you share cpu-profile of before | after reuse watcher

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working pending triage The issue/PR is currently untouched.
Projects
None yet
Development

No branches or pull requests

2 participants