-
Notifications
You must be signed in to change notification settings - Fork 12.9k
Make useFsEvents as default strategy for the watching #50366
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
Conversation
@typescript-bot pack this |
Heya @sheetalkamat, I've started to run the tarball bundle task on this PR at 61a99bf. You can monitor the build here. |
Hey @sheetalkamat, I've packed this into an installable tgz. You can install it for testing by referencing it in your
and then running There is also a playground for this build and an npm module you can use via |
I wonder if you can see a change in TSServer perf tests. @typescript-bot perf test this |
Heya @DanielRosenwasser, I've started to run the perf test suite on this PR at 61a99bf. You can monitor the build here. Update: The results are in! |
@DanielRosenwasser Here they are:
CompilerComparison Report - main..50366
System
Hosts
Scenarios
TSServerComparison Report - main..50366
System
Hosts
Scenarios
Developer Information: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had trouble following some parts.
@amcasey any other feedback or is this good to go.. I would like to get this in sooner than later. Thanks |
That's fair. I do think we should keep an eye out and revisit. My impression is that Windows and macOS, I assume this almost never makes a difference; but on Linux, it will be pretty common to hit the file watching limit, so we may still end up installing a lot of file-watchers and it would be good to improve the situation. Let me know if that's an accurate assessment. |
Yes thats true.. also many users just increase limit of native file watchers instead of opting for fallback but then this was before things were not easily configurable. Definitely can revisit this at later point. |
@sheetalkamat have to say I thought the blog post was interesting! I just did a deep dive on file-watching in Go for Pulumi and we ended up using a Rust binary to ship the feature. Does this implementation of file-watchers use ignore files at all, to reduce the number of system calls needed to monitor a directory containing, e.g., node_modules? |
Love to find the community of people banging their heads against cross-platform file-watching! During review of the blog post @sheetalkamat mentioned there's a few specific things in editor scenarios where we watch the |
As daniel mentioned, we watch node_modules instead of watching each file in editor scenarios. But apart from that when watching node_modules recursively, we have been ignoring files/directories starting with "." in |
Now that we have gotten better at handling inode movement etc and many people have tried using
useFsEvents
as default for watching files, make it default. This should give more agile callbacks compared to polling especially if it involves lots of files. It should also be better on CPU.One catch on systems which have limits on fs watchers like linux, it would still fallback to polling but that was anyways done for the recursive directory watching so files is no different, but quantity varies so something to keep in mind.
This change also ensures that fsWatches are cached and reused with multiple callbacks instead of creating different fs watcher.
Most of the changes are refactoring on better baseline test infra update
10a7b4e actually has change to make fsEvents as default for file watching
61a99bf has change to cache the watches per name even when using fsEvents