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

[Maxim Kartashev]

> Did you get anything on memory and gc as well?
I did measure memory consumption and didn't measure gc; all in all, I don't
think it's representative as neither implementation allocates much in
response to outside events.

On Fri, Nov 11, 2022 at 3:22 PM Michael Hall <mik3hall at gmail.com> wrote:

>
>
> 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> wrote:
>
>>
>>
>> On Nov 10, 2022, at 7:12 PM, Michael Hall <mik3hall at gmail.com> wrote:
>>
>>
>>
>> On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <
>> 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> 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/e90aa154/attachment-0001.htm>