Change:
There is signed of the explorer getting slower during the last days: <img width="387" alt="screenshot 2018-12-06 at 14 06 20" src="https://user-"
adding cos is busy and you probably know the explorer well... Not sure that promise adoption caused this - file operation have always been properly async...
One of my suspisions might be the changing of startup phases in addition to promise adoption. has the overall startup speed changed, or only the explorer got slower? Also can you see the change when you measure locally? If yes we can do some bisection to find the cause. Did all viewlets get slower? Also there has been no code changes in the explorer this milestone thus my reason for suspecting other things.
My =change touched a ton of promises, not just file service, so it could well be related. I saw a bit of places in the file service that were not truly async, e.g. where was used.
Blaming this on the promise-adoption is easy, but we all know by now they run on and it would require loads of them to get 50ms extra...
I am not worried about the time a takes, but rather the fact that our execution order of things on startup is changing by adopting because we have many places where code is now running on that previously was running sync in places where we wrapped a complete value into a promise under certain conditions.
Maybe I understood wrong but that shouldn't happen unless those things also run via , right? Ticks (multiple) are processes at the end of an event loop cycle and only then comes the next event.
yeah that might be true (hopefully is). I am running test now on Linux with a commit from 26th of November vs. today to see if there is something.
Bisecting on Linux I see a slowdown from to for the restoring of viewlet through:
Nice find, I will verify on Windows. I verifeid that on OS X there is no slowdown, which is correlated to the fact that menus are the cause (since we do not use custom menus on OS X)
To proove the theory: disabling custom title bar on Linux restores the good time for me on that commit.
does the overall startup time get 50ms slower too, or is it just reflected in the explorer?
I'd say that's because 99% of startups open the explorer when opening the editor. These are great findings.
it looks like the workbench ready time is actually worse when the native menu is enabled for me, so overall I see no total slowdown. Also the editor restore seems to be roughly the same with custom and native title.
this seems to be caused by  being called during startup which seems to access DOM properties that cause a forced layout. If I comment out that method, I see the normal times reported. I suggest you check if this method could be called after a delay, e.g. via

Discussion:
private numMenusShown: number; private menuStyle: IMenuStyles; <ins> private overflowLayoutScheduled: IDisposable; </ins> constructor(private container: HTMLElement, private options: IMenuBarOptions = {}) { super();

DOM.removeNode(this.overflowMenu.titleElement); DOM.removeNode(this.overflowMenu.buttonElement); <ins> this.overflowLayoutScheduled = dispose(this.overflowLayoutScheduled); </ins> } blur(): void {

this.updateLabels(menuBarMenu.titleElement, menuBarMenu.buttonElement, menuBarMenu.label); }); <del> this.updateOverflowAction(); </del> <ins> if (!this.overflowLayoutScheduled) { this.overflowLayoutScheduled = DOM.scheduleAtNextAnimationFrame(() => { this.updateOverflowAction(); this.overflowLayoutScheduled = void 0; }); } </ins> this.setUnfocusedState(); }