Prevent DevTools OOMs

[kenzieschmoll]

We may be able to get a memory pressure event from chrome that we can listen for and act accordingly to preserve memory resources.

For example, if the user has opened multiple DevTools screens, all of those screen controllers may be collecting data from the VM and slowly increasing the overall DevTools memory consumption. If we are nearing OOM, we should shut down resources we aren't using (like screen controllers from inactive screens).

We likely want to warn the user that we are running low on memory and that we are going to destroy some data on other screens, otherwise they might get frustrated that the timeline trace or the CPU profile they were just looking is now gone.

[BrianCraig]

Hey Kenzie,

I manage a Github repository dedicated to building devtools on native platforms: link. I've noticed a significant performance boost with the native devtools compared to the web-based version. They consume about one-third of the memory, are far more responsive, work well on low-end machines, and offer access to heavier usage.

I'm curious if the team has considered transitioning to shipping Devtools as native runners rather than embedded webviews?

Best, Brian

[kenzieschmoll]

Hi Brian. Yes this is something we have considered (tracking issue). We have a few limitations that would prevent us from shipping a full version of DevTools on desktop. Some of our tools use embedded iFrames that only work on the web. For example, our performance tools embed the Perfetto trace viewer in an iFrame and DevTools extensions are embedded Flutter web apps. We'd need to either redesign our web-only features or we'd require web view support on Flutter desktop to overcome these limitations.