<table><tr><td style="">rjvbb updated this revision to Diff 19339.<br />rjvbb edited the summary of this revision. <a href="https://phabricator.kde.org/transactions/detail/PHID-XACT-DREV-mfxvrqtwg6wmiua/" rel="noreferrer">(Show Details)</a><br />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><p>This new version still makes creating dir watchers optional but in addition moves their creation to after the project has been imported instead of before even starting the import. The goal is of course to defer their creation until after all projects have been imported but even for a single project there should be some gain as this avoids having 2 concurrent trawls of the same directory.<br />
This makes the patch a little bit more complicated (new watcher creation functions in AbstractFileManagerPlugin and ProjectController) but I think it's worth it as it will also allow to implement things like asking the user if watchers are to be created when a large project is detected.</p>

<p>Moving the watcher creation trigger into the ProjectController means I more or less had to merge <a href="https://phabricator.kde.org/D7745" style="background-color: #e7e7e7;
          border-color: #e7e7e7;
          border-radius: 3px;
          padding: 0 4px;
          font-weight: bold;
          color: black;text-decoration: none;" rel="noreferrer">D7745</a>, which shouldn't be an issue since we were already discussing the parser in this ticket.</p></div></div><br /><div><strong>CHANGES TO REVISION SUMMARY</strong><div><div style="white-space: pre-wrap; color: #74777D;"><div style="padding: 8px 0;">...</div>This was observed on Mac while reopening an session that contained projects for the gcc 6.3.0 and 7.1.0 source trees. Monitoring on-disk changes is unreliable on that platform (= never worked for me) so the workaround is trivial for this kind of projects: don't create KDirWatcher instances for "huge" projects. With that workaround even the gcc projects load in what seems to be a reasonable time; exitting KDevelop becomes a lot faster too.<span style="padding: 0 2px; color: #333333; background: rgba(251, 175, 175, .7);"><br />
<br />
</span></div></div></div><br /><div><strong>CHANGES SINCE LAST UPDATE</strong><div><a href="https://phabricator.kde.org/D7742?vs=19321&id=19339" rel="noreferrer">https://phabricator.kde.org/D7742?vs=19321&id=19339</a></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>AFFECTED FILES</strong><div><div>kdevplatform/interfaces/iprojectcontroller.cpp<br />
kdevplatform/interfaces/iprojectcontroller.h<br />
kdevplatform/project/abstractfilemanagerplugin.cpp<br />
kdevplatform/project/abstractfilemanagerplugin.h<br />
kdevplatform/shell/projectcontroller.cpp<br />
kdevplatform/shell/projectcontroller.h<br />
kdevplatform/shell/settings/projectconfig.kcfg<br />
kdevplatform/shell/settings/projectpreferences.ui</div></div></div><br /><div><strong>To: </strong>rjvbb, KDevelop<br /><strong>Cc: </strong>kossebau, arrowdodger, brauch, zhigalin, kdevelop-devel, geetamc, Pilzschaf, akshaydeo, surgenight<br /></div>