[Dark Shell] Win: Slow menu drawing at startup

[gruehle]

Steps to repro

1. Launch Sprint 30 on Windows.
2. Select Debug > New Brackets Window and watch how fast the menu is drawn in the new window
3. Now launch Sprint 31 and do the same thing

Results

When the second window opens, you can clearly see the menus being drawn one at a time.

[gruehle]

Medium priority for now. I'm running in a VM, which could be contributing to the slowdown. Someone who isn't running a VM should check the performance differences between Sprint 30 and Sprint 31.

Also, this could be a CEF issue instead of a Dark Shell issue, since we pulled in a new CEF for Sprint 31.

[redmunds]

I am seeing this on Native Windows 7 on my Lenovo W510. It's not always noticeable, so it may be dependent on what else is running on my computer.

[RaymondLim]

I'm seeing it on my Win 7 (Lenovo W510), not only for secondary windows, but also for the main window.

[redmunds]

I meant to say I'm seeing it on main window.

[peterflynn]

I see it on the main window as well -- changing title to reflect that

[peterflynn]

Do we know if this slows down startup overall? I can't imagine that the code in DefaultMenus normally takes that long to run. Is it just the native painting side that's slow, but it's parallelized with other startups tasks continuing on the JS side? Or does the JS side actually get stuck waiting between each call in DefaultMenus?

[peterflynn]

Nominating for Sprint 34 to at least investigate a bit

[redmunds]

I'm seeing a general slowdown during startup on Windows. Slow menu drawing maybe just be a symptom.

[redmunds]

FBNC back to @gruehle

[gruehle]

The menu drawing is definitely better, but startup time is still pretty slow. Should we have a new bug on the slow startup time?

[JeffryBooher]

@gruehle I'm not sure how much of the startup time lag is related to dark shell or not but we definitely need to profile the shell on Windows. @redmunds did some of the work and got the low-hanging fruit. My guess is that there could be a performance hit on startup with newer versions of CEF. I think as a first step we should graph startup times of various releases over a the last 6 or 8 months. I say 8 months because we had a period where we had the same version of CEF for a year and 6 months ago we started a regimen of updating CEF more frequently. We don't need to do profile every sprint release but it would be good to know with each new CEF build or even once a month. Maybe we already have that data?

[JeffryBooher]

@dangoor I added a note about getting a graph of startup times to the performance notebook http://titanpad.com/BracketsPerf

[dangoor]

@JeffryBooher we had been running performance tests from sprint-to-sprint, but it was a lot of work to keep up with relatively little useful info, as we saw it. Having some way to measure performance change over time would be valuable, but I wouldn't want to fill this bug with that discussion.