<table><tr><td style="">rjvbb added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D7742" rel="noreferrer">View Revision</a></tr></table><br /><div><div><blockquote style="border-left: 3px solid #a7b5bf; color: #464c5c; font-style: italic; margin: 4px 0 12px 0; padding: 4px 12px; background-color: #f8f9fc;"><div class="remarkup-code-block" style="margin: 12px 0;" data-code-lang="text" data-sigil="remarkup-code-block"><pre class="remarkup-code" style="font: 11px/15px "Menlo", "Consolas", "Monaco", monospace; padding: 12px; margin: 0; background: rgba(71, 87, 120, 0.08);">I think the proper solution is to see if one can use that API to watch things on macOS. It can't be that it's not possible to watch a whole directory for changes on that OS with less than 15 minutes of setup time ...</pre></div></blockquote>

<p>No, I've never claimed it is. That timing figure is real and wasn't obtained on a system that was about to crash or force me to log off. So even if it's a freak measurement it's not one I want to discard entirely, but use as an indication that dirwatching set-up time can become really long. I've never been able to reproduce timings that long with the same projects and deferral deactivated via the env.variable but dirwatch deferral does reduce the import time sufficiently that I for one appreciate the possibility to use it (see the timings I posted).</p>

<p>Note that the above timing results come from the KDirwatch qfswatch (QFileSystemWatcher) autotest tool, and QFSW uses the FSEvent event API on Mac. Compare the timings, the CPUs and filesystems and draw your own conclusions (and correct me if mine is incorrect that a much slower system is roughly 25% faster in this aspect).<br />
I'll definitely be having a look at how QFSW performs on Mac at some point, but I'm not going to entertain the idea that it can be improved significantly (by me).</p>

<p>Also check the notes in Qt's QFSW documentation, specifically what they say about BSD. It is claimed that the open file descriptor limit doesn't apply to the current Mac OS, but underneath that unlimited FSEvents API is still a BSD variant. Somehow FSEvents must be dealing with those limits, hiding them from us (the code included) ... and maybe that's what makes it inherently costly (despite all the talk about being fast and lightweight).</p>

<p><a href="https://en.wikipedia.org/wiki/FSEvents" class="remarkup-link" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/FSEvents</a><br />
(and for future reference)<br />
<a href="https://developer.apple.com/library/content/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html" class="remarkup-link" target="_blank" rel="noreferrer">https://developer.apple.com/library/content/documentation/Darwin/Conceptual/FSEvents_ProgGuide/Introduction/Introduction.html</a></p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R32 KDevelop</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D7742" rel="noreferrer">https://phabricator.kde.org/D7742</a></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop, mwolff, brauch<br /><strong>Cc: </strong>mwolff, kossebau, arrowdodger, brauch, zhigalin, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight<br /></div>