Antoine points out that Chrome Apps today have Chrome renderers and so they also introduce a compositor thread and all associated overheads so perhaps we're no worse than before. However, this also isn't a very scalable system. Part of the Mus+Ash effort has been about dicing Ash into multiple apps (although I think we've scaled back in the short term)? So we are introducing new overheads that didn't exist before.

Indeed we will have more than apps than we had before. At a minimum we'll have ash as it's own app, so that's one more. We've also split some seldom used functionality (touch-hud, auto-click) into their own apps as well. We could look to merge these if it's problematic to have more apps.

Chatting with Scott offline: In Chrome OS previously, all Chrome OS UI and browser UI had a single ui::Compositor.

In Mus+Ash, currently SysUI has a ui::Compositor, and each browser window has a ui::Compositor.

I think this will likely be an issue today with Mus+Ash.

Each mus app currently creates a SingleThreadTaskGraphRunner, which creates a separate thread. So we have one additional thread for each toplevel window. It should be possible to use at most a single thread for all windows in a client. We still end up with an additional thread for each client.

If we want to avoid this extra thread per client, we could perhaps have a TaskGraphRunner impl that runs the tasks on an existing thread (something like SynchronousTGR, but that integrates better with the SingleThreadTaskRunner, perhaps)? What kind of perf issues do we expect this to have?

OK, that's good! One thread instead of n (where n > 1)! The issue I am worried about is LayerTreeHostImpl is scheduling raster for each app separately. This might not be too bad because we do this on non-Chrome OS platforms too.

With that said, there is a possibility of some kind of regression due to the fact that we have a different scheduler in each window where we once had one scheduler.

Following up on comment #5: we already share a TaskGraphRunner for all windows in a single client. So the overhead for that now is: one additional thread in each mus app. It's not obvious to me what kind of metric would tell us how badly this is affecting performance.

sadrul@: It's not just about threads, it's also different schedulers. Rather than a single scheduler per screen, we have one per window effectively. Maybe this is not significant, maybe it is.

I would imagine CPU usage spikes would be higher if launching multiple apps in rapid succession. Not sure if there's a better way to test this...not sure...

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Migrating Proj-Mustash-Mus to components Internals>Services>WindowService and Internals>Services>Ash

Bug scrub.