689769 - (text-suck) [meta] We suck at text (in terms of memory usage)

Status: NEW

(Core :: Layout: Text and Fonts, defect)

Description

[Nicholas Nethercote [inactive]]

Inspired by bug 683284:  we use a lot more memory than other browsers on pages that have tons of text, e.g. tinderbox logs, big Mercurial changesets.  (We also do badly at text-ish/layout-ish things like tables).

This is a bug to track such cases.

Comment 1

[Justin Lebar (not reading bugmail)]

I recommend, like in bug 683284, that we limit this bug's depends list to bugs where we clearly do worse than another browser on an explicit testcase.  These bugs should be actionable.

Comment 2

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I recommend distinguishing peak memory use (page has just loaded) from long-term memory use (after the page has been loaded for a minute or more). We create a lot of temporary textrun structures that get expired after about 30 seconds, and it'll be useful to know when they're the problem (or not).

Comment 3

[Nicholas Nethercote [inactive]]

roc, what are the temporary textrun structures for, and why are they expired?

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

They're for caching the results of shaping (kerning etc) and measuring text.

They expire because after the page has finished loading (or otherwise changing) we don't need most of them anymore, and of course we want to save memory.

Comment 5

[Nicholas Nethercote [inactive]]

> They expire because after the page has finished loading (or otherwise
> changing) we don't need most of them anymore, and of course we want to save
> memory.

Why can't we just flush them as soon as we know they're finished?  Is there some uncertainty about whether they'll be needed again?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes there is, because they're needed every time we reflow the page and we don't know when that will happen. The page could trigger reflows due to scripted changes, the user could resize the window, etc.

Comment 7

[Boris Zbarsky [:bzbarsky]]

They're also needed to paint, no?  So when you're scrolling, you want to keep the textruns around for the text that's moving...

Comment 8

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, and they're needed for a few other things, but I was trying to keep the explanation simple :-)

Comment 9

[Johnny Stenback (:jst)]

Given that most of the cases where we see this we're looking at fixed width fonts (AFAICT), are there any optimizations that would be worth doing for those cases? Seems those cases ought to be significantly simpler as far as text measurement and sizing goes... Mostly thinking out loud here, so if this is clearly not worth it, then so be it.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yes, we probably could and should do something to optimize some of the common cases here.

One question is whether it's possible to detect a "fixed width" font up-front in a way that actually works correctly for common fixed-width fonts. I'm not even sure that common fixed-width fonts have exactly the same advances for every character.