chokidar

chokidar copied to clipboard

Describe the bug

Writing to a file in a watched directory should be a O(1) operation as far as chokidar is concerned, but instead in some cases the number of files in the current watched directory matters, making this a O(n) operation.

In particular when writing files atomically a temporary file is written to disk, which I think under macOS causes this function to be called, which my understanding is it scans the watched directory again, causing a significant performance issue.

Versions (please complete the following information):

• Chokidar version: 3.3.1
• Node version: 12.14.1
• OS version: macOS 10.14

To Reproduce:

I don't have a gist for this issue, but essentially one only needs to write a file atomically (or just add a new file) in a watched directory with lots of files at the top level.

Expected behavior

Writing to a single file shouldn't scale with the number of top-level files present in the watched directory.

In this particular use case I have chokidar configured to ignore the added temporary file anyway, as a quick and dirty workaround for the issue I guess before doing any potentially expensive work chokidar should check if we actually care about that added path or not.

I'm not sure why the watched directory is being scanned at all, that doesn't sound like something efficient to do when a file is being added to the watched directory 🤔

Additional context

Screenshot of the amount of work being performed when writing atomically to a single path, with ~2000 files at the root of the watched directory:

I'm not sure why the watched directory is being scanned at all

Where is it scanned, which line?

@paulmillr I guess from here:

https://github.com/paulmillr/chokidar/blob/95faa2fe42d1736b3c5bfbc0f17a9f0379b001f3/lib/fsevents-handler.js#L467-L472

If that scan is happening somewhere else instead I can still see a scan happening from the devtools, which is a problem.

If the changed file is a directory, it reads directory contents.

I'm just writing a file in the watched directory, shouldn't a scan not be triggered under that circumstance?

I don't think it should be triggered.