<div dir="ltr"><div>> Did you get anything on memory and gc as well?</div><div>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.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 11, 2022 at 3:22 PM Michael Hall <<a href="mailto:mik3hall@gmail.com">mik3hall@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Nov 11, 2022, at 3:22 AM, Maxim Kartashev <<a href="mailto:maxim.kartashev@jetbrains.com" target="_blank">maxim.kartashev@jetbrains.com</a>> wrote:</div><br><div><div dir="ltr">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.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 11, 2022 at 4:19 AM Michael Hall <<a href="mailto:mik3hall@gmail.com" target="_blank">mik3hall@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br><div><br><blockquote type="cite"><div>On Nov 10, 2022, at 7:12 PM, Michael Hall <<a href="mailto:mik3hall@gmail.com" target="_blank">mik3hall@gmail.com</a>> wrote:</div><br><div><div><br><div><br><blockquote type="cite"><div>On Nov 10, 2022, at 7:03 PM, Brian Burkhalter <<a href="mailto:brian.burkhalter@oracle.com" target="_blank">brian.burkhalter@oracle.com</a>> wrote:</div><br><div>



<div>
Near-0 CPU sounds good!<br>
<div><br>
<blockquote type="cite">
<div>On Nov 10, 2022, at 3:36 AM, Maxim Kartashev <<a href="mailto:maxim.kartashev@jetbrains.com" target="_blank">maxim.kartashev@jetbrains.com</a>> wrote:</div>
<br>
<div><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">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).</span></div></blockquote></div></div></div></blockquote><div><br></div></div>It did. Neither usage or difference seemed significant.</div></div></blockquote><br></div><div>Although Maxim saw some difference in his benchmarking. </div><br></div></blockquote></div>
</div></blockquote></div><br><div>Much more a stress test than mine. I was seeing like 0% to 0.1% for FSEvents and .1% to .2% for polling. </div><div>Did you get anything on memory and gc as well?</div></div></blockquote></div>