[CLOSED] [File watchers] Speed up project switching - don't wait for unwatch

[core-ai-bot]

Issue by peterflynn
Friday Jan 17, 2014 at 23:22 GMT
Originally opened as adobe/brackets#6573

---

PR #6548 fixed bug #6540, but it makes project switching slower as a result because we wait for all the previous project's file watchers to be turned off before we begin loading the new project. (And while we're waiting, which can be ~1 sec on Windows, the UI is in a somewhat weird intermediate state -- all your editors have closed and the working set is empty, but the file tree is still showing the old project).

Really, to avoid #6540 we just need to wait until after the FileIndex has been cleared. We don't think there's any reason that FileSystem.unwatch() can't clear the FileIndex immediately, before the unwatch is complete. If another watcher change arrives in between those two events, the code in FileSystem._handleExternalChange() will essentially no-op because this._index.getEntry() will yield undefined.

We didn't use that fix right off the bat because we wanted to have a little more testing runway just to verify that everything works... but we should switch to that fix eventually.

[core-ai-bot]

Comment by jasonsanjose
Friday Jan 17, 2014 at 23:29 GMT

---

Will PR #6565 since we will unwatch the whole project in one batch request instead of visiting the full file tree, then firing individual commands to the FileWatcherDomain?

[core-ai-bot]

Comment by peterflynn
Saturday Jan 18, 2014 at 00:04 GMT

---

@jasonsanjose I think@iwehrman had found that the actual OS-level unwatch command was the slow part, but it does seem worth testing that, yeah. Does it feel noticeably faster to you with your fix?

[core-ai-bot]

Comment by njx
Thursday Jan 23, 2014 at 17:49 GMT

---

Reviewed. Since we're planning to change Windows so that we're only watching/unwatching the root folder, it seems like this will be a lot less of an issue, so marking low pri for now. If it turns out that it's still slow after that, we can bump up the priority.

[core-ai-bot]

Comment by njx
Thursday Jan 23, 2014 at 17:49 GMT

---

To@peterflynn

[core-ai-bot]

Comment by peterflynn
Thursday Jan 23, 2014 at 21:11 GMT

---

@njx good point, I expect that would fix it 100%... so I'll mark this 'tracking' for the time being.

[core-ai-bot]

Comment by bchintx
Wednesday Jan 29, 2014 at 02:53 GMT

---

@peterflynn@njx I just compared switching between two, large projects using Brackets builds with the old fs.watch() implementation and the new native Windows node-module implementation. IMHO, it seems noticeably quicker using the native implementation.

Actually, the unwatch wasn't noticeably slower in the old implementation, but the watching of new, expanded subfolders in the switched-to project was noticeably faster in the new implementation. Seems like we got the most performance boost from not having to watch every subfolder. Yay!

I'll re-assign this bug to myself and mark it FBNC once the new implementation is merged as Pull Requests #6673 and #412.

[core-ai-bot]

Comment by peterflynn
Wednesday Jan 29, 2014 at 08:30 GMT

---

Schweet

[core-ai-bot]

Comment by bchintx
Friday Jan 31, 2014 at 22:46 GMT

---

PRs have been merged to master and Sprint 36 release. Marking as FBNC.

[core-ai-bot]

Comment by peterflynn
Thursday Feb 20, 2014 at 02:19 GMT

---

Removing FBNC since the outcome was we actually decided this change was unneeded. Closing.