I switched the Mac test machine to a more powerful Macbook pro, the following is the hardware info for that Macbook pro:

CPU: Intel(R) Core(TM) i5-4278U CPU @ 2.60GHz
Graphic Card: Intel Iris, (Dynamic, Max): 1536 MB
Memory: 8 GB
OS: Mac OS X 10.10.5
Release date: Mid-2014

Let's wait for the perf results from this machine to see if there is any improvement.

Since switching machines, the Mac latency times have dropped and held steady at:
- Paint: 583ms
- Load with data: 823ms

This is slightly slower than windows/linux, though expected because of the cocoa/views implementation difference. The delta between the two times is much greater than the other platforms, though.

Window's numbers are around 550ms (paint) to 650ms (load w/data), and Linux around 350ms (paint) to 425ms (load w/data).

Lei, what are the specs of the test Windows and Linux machines? Are they similar to the current Macbook Pro that you swapped in this week?

The following are the info for Windows and Linux machines:

Windows:
CPU: Intel(R) Core(TM) i5-3337U CPU @ 1.80GHz
Graphic Card: Intel(R) HD Graphics 4000
Memory: 4 GB
OS: Windows 7 Professional



Linux:
Brand: Lenovo
CPU: Intel(R) Core(TM) i7 CPU M 620  @ 2.67GHz x4
Graphic Card: Intel Core Processor Integrated Graphics Controller
Memory: 4 GB
OS: Ubuntu 14.04.2 LTS

Renaming as we're now concerned at the delta (ms) between initial paint and load with data.

The deltas for platforms given the machines with spec in #8 and #10 are around:
Mac: ~225ms
Windows: ~40ms
Linux: ~30ms

It seems like we can drop priority from P1?

For WebUI, the JavaScript runs in the renderer process, but the C++ handlers run in the UI thread of the browser process.

Cocoa uses UI thread blocking animations for the window modal sheets (the dialog we're using is a sheet). On Mac, some compositing is also done in the browser process rather than GPU process.

Locally running time profiles using Xcode instruments and adding logging to print the values that would be uploaded for performance tests on a chromium build yields interesting results.

The following is all n=20 on a Debug build on a mac pro with ~14 devices on the network. The Release build didn't perform much better on the mac pro, though Canary doesn't have such bad initially-open-dialog lag.

Recorded two metrics:
a) Time between user click of icon to opening the dialog
b) Time between request for initial data and data set in WebUI

(a) is 4-5s on all runs, which is way slower than what we see in the performance tests, but all my machines seem to be slow at initially opening the dialog... Currently we're just concerned with (b).

#1: Current implementation
b) 0.44s <--- slow

#2: Request initial data after ~3s (manually click button to trigger request)
b) 0.042s <--- close* to Windows/Linux load with data perf, though after a delay

#3: Request initial data after 1s (async)
b) 0.042s

#4: Request initial data after 250ms (async)
b) 0.028s

#5: Request initial data after 75ms (async)
b) 0.024s <--- better!

#6: Request initial data after 25ms (async)
b) 0.024s

It seems like an async request of the data after a short delay gives us comparable results* to Windows/Linux. If not, it's still over 15x better the changes on the mac pro.

I'll send out a CL to see how this fares in the tests. If the changes don't appear to affect the test machine positively, I'll revert it.

With the same implementation on all platforms, I expect non-mac platforms will take a slight hit from the extra 25ms.

* mac pro, though

When cocoa is deleted and we switch to MacViews 100%, this shouldn't be an issue anymore.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/85774de241f2c818a678d490c362e322f6036752

commit 85774de241f2c818a678d490c362e322f6036752
Author: apacible <apacible@chromium.org>
Date: Mon May 16 23:07:39 2016

[Media Router WebUI] Import some Polymer elements after initial load.

Not all of the Polymer elements imported into media-router-container are needed on startup, in particular if they require user interaction to trigger. This change moves some of them to be imported afterNextRender().

It would be great to move everything unused at initial load (e.g. route_details.html), but initial data may return before afterNextRender() is called.

Initial data load times (n=20 runs, Debug build on Mac):
Before: 4.3921s
After: 4.1791s

BUG= 549289 ,  599693 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1986543002
Cr-Commit-Position: refs/heads/master@{#393969}

[modify] https://crrev.com/85774de241f2c818a678d490c362e322f6036752/chrome/browser/resources/media_router/elements/media_router_container/media_router_container.html
[modify] https://crrev.com/85774de241f2c818a678d490c362e322f6036752/chrome/browser/resources/media_router/elements/media_router_container/media_router_container.js

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5c14299c1f3b0ff1926b9e05607afd96cfadd809

commit 5c14299c1f3b0ff1926b9e05607afd96cfadd809
Author: apacible <apacible@chromium.org>
Date: Tue May 17 00:17:43 2016

[Media Router WebUI] Add slight delay before requesting initial data for Mac.

From some investigation looking into the bottlenecks of initial open/load time of the Media Router dialog (see comment 15), waiting a short amount of time before requesting data speeds up the data request time by over 15x.

It would be good to see if this change is also reflected in the performance tests in the lab.

BUG= 599693 
CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/1984743002
Cr-Commit-Position: refs/heads/master@{#393990}

[modify] https://crrev.com/5c14299c1f3b0ff1926b9e05607afd96cfadd809/chrome/browser/resources/media_router/elements/media_router_container/media_router_container.js
[modify] https://crrev.com/5c14299c1f3b0ff1926b9e05607afd96cfadd809/chrome/browser/resources/media_router/media_router.js

As of 05.16, the difference between paint and load with data is roughly ~50ms for Mac, which is on par with Windows/Linux.

The paint time in general still have a gap between platforms:
- Linux is steadily decreasing, now at about 350ms (from 410ms).
- Windows is wildly inconsistent, reporting numbers from 450ms to 700ms.
- Mac holds steady at about 850ms.

Great work.  It sounds like this can be closed if you feel the results will hold up.

Closing this; tracking paint time in crbug/549289