-
Notifications
You must be signed in to change notification settings - Fork 7.6k
Clicking on items in the working set seems slow #9439
Comments
(BTW, this is running off the release branch with the leaky listener fix. I'm not sure if this is something that gets worse over time - when I restarted Brackets it didn't seem quite as severe.) |
@njx I made some serious improvements to the way way panes are focused and activated and delay creating the drag ghost until you drag so, if you want to give it a whirl, the changes are in |
following a note by @ilkkanisula on #9486 I hid the sidebar and noticed an immediate improvement in performance with file switching (mid-2012 MPB-retina, i7/8gb/10.9.5). Clicking a file in the sidebar is terribly slow can take up to 2s to switch. Ctrl+tabbing with the sidebar open is also sluggish though not as bad (~1s). But with the sidebar hidden, ctrl+tab file switching is pretty quick, i'd guess ~ 300ms. New to brackets, I haven't used previous releases, though I have compared it with Edge Code (whatever release that's based on) and found ctrl+tabbing to be instantaneous, and clicking items in the sidebar is quick though still noticeably slower than any other text/code editor (atom, for example). |
I have tested this fix on my system and found that clicking on working set items now appears to have similar performance to doing the same action in 0.43. In the timeline, the mouseup event in 0.44 spent over 3x the time in layout as master or 0.43, ~750ms vs. ~200ms. That accounted for nearly all of the slowdown. We definitely want to improve file switching speed farther, but this change did fix the performance regression. |
I'll also just note that my test was switching between the same two specific files in the Brackets project in 0.43, 0.44 and master (e080eb6) |
Confirming that 0.45.0-14936 (master 5a05eaa) is faster with text rendering with sidebar and with sidebar hidden. Scrolling is smoother and typing is more responsive. (Macbook 2008, OSX 10.7.5) |
Selecting items in the working set seems noticeably sluggish, at least on the Mac. I went back and looked at the previous sprint build, and it seems like there's a greater pause between when the filename updates in the title bar and the editor content updates.
Looking at the timeline, it seems like there's a lot of whole-document style recalculation and re-layout happening in updating the working set selection, and it's happening multiple times during a single click.
I don't think this is stop-ship for 0.44, but we should dig into this in 0.45 since it's a noticeable performance regression.
The text was updated successfully, but these errors were encountered: