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

[Maxim Kartashev]

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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20221111/e351bbde/attachment.htm>