-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Using FileWatcher on non-windows has a very large impact on startup time #42036
Comments
Related issue in the runtime RE swapping to newer Linux API that could improve this #30495 |
Tagging subscribers to this area: @eerhardt, @maryamariyan |
Tagging subscribers to this area: @maryamariyan |
@rynowak did you get a chance to also do the same measurements on linux? |
Newp. |
Related to dotnet/aspnetcore#20488
I did some investigation about some startup cost of the filewatching we set up by default. What I found may shock you. In the case that I'm measuring on macOS - the impact of first call to
IFileProvider.Watch()
is 100ms in wall clock time.Background
Some background...
One of the features of
IFileProvider
is that it implements globbing in a non-OS-native way. SoIFileProvider
implements file system globbing/**/*.cshtml
which is separate from what the underlying OS does.IFileProvider
also implements file-watching, and since you have mix globbing (not implemented by the OS) and file watching (implemented by the OS) it uses a big hammer to implement this. WhenWatch
is called,IFileProvider
will watch the entire directory hierarchy it has access to, and will do the filtering of notifications based on the globbing feature.On windows watching a directory tree maps directly to the Win32 API FindFirstChangeNotification or ReadDirectoryChanges. So watching a directory and it's subdirectories is implemented by the OS directly, and it takes one call from .NET -> native to set this up.
On Linux, there isn't an API for recursive subdirectory watching, the filewatcher code has to walk the directory hierarchy and register a watch on each subdirectory.
On macOS there is an API for recursive file watching. So it's not totally clear why it's taking 100ms.
How I'm measuring
I wrote the following test code:
Publishing this with
-c Release
and then running it repeatedly yields pretty consistent results with a variation of about ~10ms. This is measured with the MVC template, which has some files to watch. Note that I'm doing a publish so that we're measuring all of the files that need to be in the app's output, not measuringobj/
.Results on macOS
Next Steps
My next step here is to retake these measurements on Linux. We care a little bit more about Linux as a production scenario.
I can measure that this is pretty slow on macOS, but it's not slow for the reasons I expected. Using
FileSystemWatcher
andIFileProvider.Watch
had the same result.The text was updated successfully, but these errors were encountered: