1925733 - Since 9Oct2024, web-compat interventions changesets show a strong correlation with increase in AWSY- Base-content-heap-unclassified

Status: RESOLVED WONTFIX

(Core :: Performance: General, defect)

Description

[Mayank Bansal]

See this graph.

0.5% regression around 10Oct2024 (+10308 Bytes)
0.7% regression around 16Oct2024 (+14976 Bytes)

I only have 2 datapoints, but those two strongly coorelate with the web-compat interventions. Maybe there is some leak or maybe there is memory overhead of loading the file, but 0.7% and 0.5% seem to on the larger side.

The graph is only for heap-unclassified on Linux, but there may be impact on other memory metrics too.
And I am pretty sure there were regression on OSX and Windows too.

Caveats:

1. The magnitude of these regression may be small enough to ignore and/or not worth spending time
2. I am just seeing things where none exist

cc - :twisniewski , :continuation

Comment 1

[Mayank Bansal]

See this graph for Windows. There are spikes in the same period, but its not 100% clear to me what could have caused those. Though the web-compat changes are in that range.

Comment 2

[Thomas Wisniewski [:twisniewski]]

This doesn't really make much sense to me, as if these kinds of webcompat interventions caused the heap to spike like this, we should have seen this kind of increase over time as we add interventions, not just now all of a sudden (or maybe we have just not noticed it until now?). That, and I have no idea why it would be unclassified content memory which rose, as our addon only runs content-scripts and alters web-page content with those (and I would have hoped those kinds of changes would be classified in some way).

So either we're just hitting some kind of unanticipated limit in the web-extension APIs we rely on, and internal code is doing something funky (which seems unlikely, given that we've not added that many interventions), or perhaps the "are we slim yet" tests are checking one of the pages for which we've added an intervention, and somehow the natural increase in memory usage on that page counts as "unclassified", and will only affect folks who run that page.

But the only intervention we've so recently shipped which I can imagine raising memory usage on a page we might measure is for TikTok, to fix broken captchas, so I don't know why we'd see two spikes (though I don't know which pages we might be testing, and we did add CSS style alterations to Google properties as well, which we've done before from time to time). Also I don't know if we could really do much about the memory increase for that intervention, nor can I tell how severe it really is, or if it would affect all users, or just folks browsing on TikTok. So unless we can find any more clues, we might want to just live with this increase for benefit it brings to affected users (and hopefully the increase goes away when we un-ship which intervention causes it).

And if we're hitting internal pathological code issues with web-extensions, I fear we might just see this increase even more over time, as we do need to ship even more webcompat interventions (we have a backlog that we're working on now). In that case if the increase is unacceptable we'll have to find out what's going on with the addons team, and optimize whatever we need to optimize.

Comment 3

[Mayank Bansal]

With the patches from bug 1927603, the heap-unclassified has improved! (-15680 Bytes)

Comment 4

[Andrew McCreight [:mccr8]]

Sorry, I meant to comment in here earlier. I wouldn't worry too much about a small increase in heap-unclassified caused by adding a bit more JS.

Comment 5

[Thomas Wisniewski [:twisniewski]]

Yeah, then that win should be from us removing some JS webcompat interventions in that patch. I would only really worry if we add in an intervention which proves to be grossly inefficient, but we do try to ensure they're minimal.