RFR: 8293067: (fs) Implement WatchService using system library (macOS) [v9]

[Michael Hall]

> On Nov 11, 2022, at 3:22 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com> wrote:
> 
> I imagine it's hard to get anything above 0% when watching just one directory, nor is it representative of the use case I'm interested in (a source code tree). My experiment was with a recursive watch of 50K files in 6K directories, 19K modifications done (files modified, added, removed, directories added) in 8 minutes. That generated ~17% sys, ~7% user (24% of one CPU overall) with the polling watch service.
> 
> On Fri, Nov 11, 2022 at 4:19 AM Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
> 
> 
>> On Nov 10, 2022, at 7:12 PM, Michael Hall <mik3hall at gmail.com <mailto:mik3hall at gmail.com>> wrote:
>> 
>> 
>> 
>>> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <brian.burkhalter at oracle.com <mailto:brian.burkhalter at oracle.com>> wrote:
>>> 
>>> Near-0 CPU sounds good!
>>> 
>>>> On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <maxim.kartashev at jetbrains.com <mailto:maxim.kartashev at jetbrains.com>> wrote:
>>>> 
>>>> I benchmarked this implementation (well, the implementation this one is based on, now it's become quite different) extensively. The main advantage of FSEvents over polling was near-0 CPU usage when there were small number of changes to the directory being watched, while polling naturally always has some background job to do and its CPU usage heavily depends on refresh speed (like 25% with SENSITIVITY_HIGH and modest rate of changes).
>> 
>> It did. Neither usage or difference seemed significant.
> 
> Although Maxim saw some difference in his benchmarking. 
> 

Much more a stress test than mine. I was seeing like 0% to 0.1% for FSEvents and .1% to .2% for polling. 
Did you get anything on memory and gc as well?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/acfa7ac5/attachment.htm>