FSWatcher.close() incurs a big performance cost in >=10.16 #29949

Activity

1. jonjaques

   changed the title [-]fs.FSWatcher.close() incurs a (large) performance decrease in >=10.16[/-] [+]FSWatcher.close() incurs a performance decrease in >=10.16[/+] on Oct 12, 2019
2. jonjaques

   changed the title [-]FSWatcher.close() incurs a performance decrease in >=10.16[/-] [+]FSWatcher.close() incurs a big performance cost in >=10.16[/+] on Oct 12, 2019
3. Fishrock123

   added

   fsIssues and PRs related to file-system APIs and the fs module.Issues and PRs related to file-system APIs and the fs module.

   on Oct 14, 2019
4. sebdvd commented on Sep 9, 2021

   

   sebdvd

   on Sep 9, 2021

   More actions

   • Version: 14.17.6
   • Platform: macos 11.5.2
   • Subsystem: fs

   Hello, I noticed too that closing a lot of fs.FSWatcher instances were slow. I recently migrated some big projects to webpack@5 and webpack-dev-server@4, and I noticed that closing the dev server was slow (cf. discussion here webpack/webpack-dev-server#1479 (comment)). I dug in the source code and found that the webpack watch feature uses watchpack@2 and fs.watch and takes a lot of time to close all the watchers. In my case it was about closing ~1200 fs.FSWatcher. So I wrote a few lines of code to reproduce this issue:

   const fs = require('fs');
   const watchers = [];
   for (let n = 0; n < 1200; n += 1) {
     watchers.push(fs.watch(process.cwd()));
   }
   console.log('closing watchers...');
   console.time('closed');
   for (let w of watchers) {
     w.close();
   }
   console.timeEnd('closed');

   On my laptop it's quite slow, here the output:

   ➜ for i in {1..5}; do node script.js; done
   
   closing watchers...
   closed: 5.244s
   closing watchers...
   closed: 5.247s
   closing watchers...
   closed: 5.217s
   closing watchers...
   closed: 5.272s
   closing watchers...
   closed: 5.242s
   
5. heyimalex commented on Aug 5, 2022

   

   heyimalex

   on Aug 5, 2022

   More actions

   Noticing a similar issue on macOS Monterey 12.4, intel, node: v16.16.0. Closing a watcher takes up to 50ms, so closing 1k+ in a tight loop leads to the process being busy for many seconds. Reproducing is trivial: create 5k watchers and then time the closes:

   const fs = require("fs");
   const { performance } = require("perf_hooks");
   
   const filenames = [/* 3k+ paths to files/directories */]
   
   filenames
     .map((filename) => fs.watch(filename))
     .forEach((watcher) => {
       const start = performance.now();
       watcher.close();
       const duration = performance.now() - start;
       console.log(duration);
     })

   From the output of this it's pretty clear what's happening: the first durations printed are ~35ms and they gradually decrease to sub-ms times, so FSWatcher.close performance scales with the total number of watchers open. Here's close duration plotted against watchers open.

   

   Encountered this issue inside watchpack which "intelligently" replaces non-recursive watchers with recursive watchers when the total number of watchers hits some limit. When this replacement happens, watchpack will close the already-opened watchers, and if there are already a lot of files being watched this can take a long time.
6. sokra

   added 2 commits that reference this issue on Dec 10, 2024

   Limit the number of concurrently open file watchers on macos

   ...

   456589a

   Limit the number of concurrently open file watchers on macos (#73741)

   ...

   416c137
7. github-actions commented on Jun 27, 2026

   

   github-actionsbot

   on Jun 27, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been marked as stale due to 210 days of inactivity.
   It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.
8. github-actions

   added

   staleIssues and PRs marked stale due to inactivity and scheduled for automatic closure.Issues and PRs marked stale due to inactivity and scheduled for automatic closure.

   on Jun 27, 2026
9. github-actions commented on Jul 28, 2026

   

   github-actionsbot

   on Jul 28, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been automatically closed after 30 days of inactivity following its stale status (no activity for a total of 120 days).
   If this is still relevant, feel free to reopen it or leave a comment with additional details so we can continue the discussion.
10. github-actions

    closed this as not plannedon Jul 28, 2026