Reduce memory footprint of sidebar

[twschiller]

Context

• The onboarding playground work is exposing some performance problems when many extensions are active

Things to Explore

• On 1.7.3-beta.1 build, the sidebar memory footprint is nearly 20mb of strings

Questions

• How to profile the content script? I originally wanted to profile the content script, but I profiled the sidebar because I was able to snapshot its heap

Screenshots

• Is FontAwesome all being loaded into memory as strings?

• Extension is loading all team members from organizations if you're an admin

• Why is the getMarketplaceListings endpoint being called from the sidebar? Or is the profile showing the heap from elsewhere? It be coming from BrickIcon?

• Why are we missing out on string interning? Note the duplicate strings:

[fregante]

How to profile the content script?

Doesn't it show up as part of the same view as a regular page?

Is FontAwesome all being loaded into memory as strings?

Font Awesome is not treeshaken, so importing one icon leads to the whole library being loaded into memory. A solution to this (and to other icon issues) was suggested in https://github.com/pixiebrix/pixiebrix-extension/issues/2019

As always the best thing is to limit our usage of icon libraries because so far we have 5+ separate libraries, mostly for the users, but we also import some directly.

Extension is loading all team members from organizations if you're an admin

Why is the getMarketplaceListings endpoint being called from the sidebar? Or is the profile showing the heap from elsewhere? It be coming from BrickIcon?

I think they're not being called but they just exist in memory because of the monolithic structure of the bricks. Every context loads every brick whether they're used or not.

Why are we missing out on string interning? Note the duplicate strings:

Probably a microoptimization at this point.

[fregante]

😌

[twschiller]

Doesn't it show up as part of the same view as a regular page?

For the memory profiler, I only see the sidebar page. I thought each content script gets its own VM, so would have expected it to be in there

As always the best thing is to limit our usage of icon libraries because so far we have 5+ separate libraries

Agree. I don't think it's driving the crashing problem we were seeing on the new playground blueprint. So will punt for a bit longer.

I think eventually we move the icon library out of the extension bundle and host on our server. The original intention was to not leak information about what icons the person is using if the user was using local mode. But we have that information on our server anyway since we host the blueprint/brick content and haven't seen any interest in local mode

Why is the getMarketplaceListings endpoint being called from the sidebar?

That particular API endpoint I don't think it in a call path from the sidebar. I also don't see network calls for it. So I'm a bit stumped on how content for it is seemingly making its way into the heap snapshot

Probably a microoptimization at this point.

Agree. Chrome makes it hard to see how much of the string memory content is

[twschiller]

Leaving this issue open after 1.8.2 as there's still some potential memory issues for users with access to a large amount of content

For 1.8.2 we made a series of improvements to improve memory utilization:

• Use mountOnEnter for Mod Launcher and Activation tabs to prevent unnecessarily fetching mod definitions
• Use mountOnEnter for sidebar panel mods
• Lazily load the code for the Mod Launcher and activation tabs

On my setup, the main memory utilization comes from fetch mod details for the mod launcher. That's because I have access to a lot of content, some of with which large images/wordlists in the content. (See the "String" in the summary graph above)

• Loading all mod definitions from IDB into memory
• Fetching/Loading all marketplace data into memory

To reduce the memory footprint, we could discard irrelevant information after fetching it. However, there's some challenges to that:

• IIRC, we currently need the entire mod definition to determine mod component types for the launcher

[github-actions[bot]]

This issue will be closed in 7 days unless the stale label is removed, or a comment is added to the issue.

[github-actions[bot]]

This issue was closed because it has been stale for 7 days with no activity.