MathML very slow on large pages after bug 114365

RESOLVED FIXED in mozilla34

Status

()

defect
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: bruce.miller, Assigned: jkitch)

Tracking

({regression})

28 Branch
mozilla34
x86_64
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(3 attachments, 8 obsolete attachments)

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140717120014

Steps to reproduce:

Visit http://dlmf.nist.gov/10.22


Actual results:

took > 60 seconds to render the page


Expected results:

should have taken <5 seconds, as did Firefox 25.
After looking at many forum discussions about slowness, I tried several things:
factory reset, safe mode, hardware accelleration on/off, disabling cairo,
disabling javascript.  None made any significant difference.

I'm not sure if this started in release 27 or 28; it's still there in 30.

I'm assuming MathML is a relevant component here: While Firefox 28 _may_ be somewhat
slower than 25, in general (I didn't benchmark anything), it is _dramatically_ slower
on pages with significant MathML content (such as the above URL).
I doubt if this is relevant, but even with javascript disabled, I see
this message in the console, upon startup:
mutating the [[Prototype]] of an object will cause your code to run very slowly; instead create the object with the correct initial [[Prototype]] value using Object.create Preferences.jsm:378
I'm adding a dependency on bug 1009582 here, although the cause seems older.

Can you try http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/ and say at which version this started precisely...
Depends on: 1009582
Flags: needinfo?(bruce.miller)
It appears to have slowed down significantly already in the 1st beta (28.0b1) whereas
the last minor release of 27 (27.0.1) is fine (although it was released later than 28.0b1,
obviously without some of the latest experimentation! :> ).  Hope that helps narrow it down.
Flags: needinfo?(bruce.miller)
(In reply to Bruce Miller from comment #4)
> It appears to have slowed down significantly already in the 1st beta
> (28.0b1) whereas
> the last minor release of 27 (27.0.1) is fine (although it was released
> later than 28.0b1,
> obviously without some of the latest experimentation! :> ).  Hope that helps
> narrow it down.

OK, thanks. The MathML bugs for Gecko 28 are:

https://bugzilla.mozilla.org/buglist.cgi?resolution=FIXED&query_format=advanced&component=MathML&product=Core&target_milestone=mozilla28&list_id=10819697

Possible candidates can be:

- bug 114365 (mathvariant). Especially because we do some stuff to keep track of what to apply to token elements and transform the characters in the text run.

- bug 415413 (intrinsic width). As I recall, there was a comment in the code that measuring the ink metrics is less efficient than using the advance width. Moreover, there is additional work to sum up individual width of text inside token elements.

So we will need to narrow that down a bit more...
@Bruce: Can you please try to do https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/?

According to https://wiki.mozilla.org/RapidRelease/Calendar#Past_branch_dates, you should do

mozregression --good 2013-10-28 --bad 2014-03-18
Flags: needinfo?(bruce.miller)
I'd be happy to try it, but there are no instructions for fedora; the github installation instructions are a long chain of "you need this or that; you might need to do this; maybe that....".  Apparently what I cloned from github doesn't run standalone...
Flags: needinfo?(bruce.miller)
Mmh, I guess one of "easy_install mozregression" or "pip install mozregression" should work as long as you have the corresponding Python env. The first worked for me.
You're right; it was an "easy install"... it's just the instructions made it seem like
it would be hard! (hmm... why does that sound familiar?!?!)... 
OK, installed and will start the search shortly.
My, what an unpleasant program (mozregression); *very* slow server & mozregression kept timing out (I guess?) Ultimately, I ended up doing the bisection essentially by hand, running mozregression 4 times.

But in the end, I narrowed it down:
2013-12-02 good
2013-12-03 bad
Thanks, so apparently, the regression is due to bug 114365 (mathvariant support):
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-12-02&enddate=2013-12-03
Depends on: mathvariant
No longer depends on: 1009582
TO REMEMBER: do https://wiki.mozilla.org/Buildbot/Talos#Adding_a_new_test

I see that the page load is a bit slow, but definitely always <5 seconds for me so I can not really confirm the bug. I've submitted a patch to the try server that disables the whole MathMLTextRunFactory (and thus breaks mathvariant support) just to see whether the issue comes from that:

https://tbpl.mozilla.org/?tree=Try&rev=02b53e76ff58

@Bruce: could you try https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/fred.wang@free.fr-02b53e76ff58 when the builds are ready (hopefully before the day wakes up in the USA!).

With the mathvariant support:

- We now map the mathvariant attributes to CSS style (should be efficient?)

- nsMathMLTokenFrame::MarkTextFramesAsTokenMathML now checks the content of each mi token frame to determine if it has only one char, and adds a frame bit if necessary. (should be relatively efficient?)

- When mathvariant is specified or when we have a single char mi, a MathMLTextRunFactory object is created and used to generate a new text run and do some remapping. (should be the problem if we does that too many times?)

The most frequent cases in the document seem to be

1) Italic single <mi> like <mi>x</mi>
2) Single char letters with mathvariant="normal" like <mi mathvariant="normal">∞</mi>
3) Single char <mi> with explicit mathvariant like <mi mathvariant="fraktur">A</mi>

I believe the creation of MathMLTextRunFactory can just be avoided in 2). More generally, I think MathMLTextRunFactory can be avoided in some cases in 1) and 3): we could just check whether the char is potentially "remappable" (that is a-z, A-Z, Arabic letters + a few exceptions like dotless i/j) and otherwise don't set anyMathMLStyling = true. Then LaTeXML (and others) could just generate the remapped char instead of using mathvariant in order to avoid the useless calls to MathMLTextRunFactory. Note sure that will completely solve the problem, though.

BTW, I'm also concerned about the ssty remapping that was done later in bug 442637 (Gecko 29), since that now almost always create a MathMLTextRunFactory.
Depends on: 442637
Flags: needinfo?(bruce.miller)
Summary: MathML very slow → MathML very slow on large pages after bug 114365
MathMLTextRunFactory::RebuildTextRun() performs three actions.

1)  Fiddles with the TextRun's gfxFontStyle
2)  Rebuilds the embedded text character by character with checks for mathvariant substitution
3)  Actually applies the textrun changes.

1) is minor.  It can be moved, providing we can find a spot that lets us modify fontstyle objects.

2) occurs every time the MathMLTextRunFactory is invoked, but I expect that this can be skipped when character transformations are not needed.  

3) is largely copy/pasted from one of the existing TextRunFactories.  It may be performing some unnecessary action.  

I'll try to run the testcase under a profiler to see if anything obvious appears.
Your hacked version loads indeed loads the page quite quickly, so the MathMLTextRunFactory seems to be where the problem comes from.  Of course, as you say, broken mathvariant (for the exotic variants) reverted as well! DLMF doesn't use those variants, in large part because Firefox hadn't been supporting them.  If a quick test can determine the need for remapping, that sounds like a good solution.
Flags: needinfo?(bruce.miller)
(In reply to Bruce Miller from comment #14)
> Your hacked version loads indeed loads the page quite quickly, so the
> MathMLTextRunFactory seems to be where the problem comes from.  Of course,
> as you say, broken mathvariant (for the exotic variants) reverted as well!
> DLMF doesn't use those variants, in large part because Firefox hadn't been
> supporting them.  If a quick test can determine the need for remapping, that
> sounds like a good solution.

However, we need a remapping for implicit mathvariant="italic" with single-char variable <mi>x</mi>, which seems ubiquitous... LaTeXML could speed up that stuff by generating the plane-1 char (as well as for bold, bold-italic, and other "exotic" mathvariants) and thus eliminating any need for MathMLTextRunFactory, but we would still have the problem of missing font coverage if no Web fonts are provided (especially on mobile). But anyway, let's see how we can optimize MathMLTextRunFactory first.
Posted patch WIP (obsolete) — Splinter Review
This is the first stab at improving performance.

RebuildTextRun() has been split up so ssty no longer triggers mathvariant code, and where possible things have been pulled outside of loops.

The earlier suggestion of testing if single char mathvariant behaviour should be triggered has been applied.
Attachment #8463368 - Flags: feedback?(fred.wang)
Comment on attachment 8463368 [details] [diff] [review]
WIP

Review of attachment 8463368 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/generic/MathMLTextRunFactory.cpp
@@ +287,3 @@
>      // nothing to do here
>      return aCh;
>    }

If you change nsTextFrame to never do the remapping when NS_MATHML_MATHVARIANT_NORMAL, I think this can be converted into an ASSERT.

@@ +523,5 @@
> +{
> +  if (('A' <= aCh && aCh <= 'Z')  ||
> +      ('a' <= aCh && aCh <= 'z') ||
> +      ('0' <= aCh && aCh <= '9') ||
> +      (GREEK_UPPER_ALPHA <= aCh && aCh <= GREEK_UPPER_OMEGA 

trailing space

@@ +524,5 @@
> +  if (('A' <= aCh && aCh <= 'Z')  ||
> +      ('a' <= aCh && aCh <= 'z') ||
> +      ('0' <= aCh && aCh <= '9') ||
> +      (GREEK_UPPER_ALPHA <= aCh && aCh <= GREEK_UPPER_OMEGA 
> +       && aCh != HOLE_GREEK_UPPER_THETA) ||

I think the && operator should be at the end of the previous line?

@@ +586,5 @@
> +
> +      In the event that the script size multiplier actually makes things
> +      larger, no change is made.
> +
> +      If the user doesn't want this to happen, all they need to do is set

"user doesn't" VS "they need"

@@ +626,5 @@
> +  else if (aFlags & MATH_FONT_STYLING_NORMAL) {
> +    fontStyle.style = NS_FONT_STYLE_NORMAL;
> +    fontStyle.weight = NS_FONT_WEIGHT_NORMAL;
> +  }
> +

I think the else's above should be

} else {
} else if {

(that is, on the same line)

::: layout/generic/nsTextFrame.cpp
@@ +1887,5 @@
> +        // All MathML tokens except <mtext> use 'math' script.
> +        textFlags |= gfxTextRunFactory::TEXT_USE_MATH_SCRIPT;
> +      }
> +      if (NS_MATHML_MATHVARIANT_NONE != f->StyleFont()->mMathVariant) {
> +        applyMathVariant = true;

It looks like mathvariant="normal" will always call the MathMLTextRunFactory. Is it necessary? I believe we only need to remove the bold/italic font-style without char remapping. Calling AdjustFontStyle below should do that if you set the MathMLTextRunFactory::MATH_FONT_STYLING_NORMAL flag.

I expect that in Bruce's example, things like <mi mathvariant="normal">x</mi> won't need any effort.

@@ +1932,5 @@
> +  uint8_t oldScriptLevel = 0;
> +  while (child->HasAnyStateBits(NS_FRAME_MATHML_SCRIPT_DESCENDANT) &&
> +         parent) {
> +    // Reconstruct the script level ignoring any user overrides. It is
> +    // calculated this way instead of using scriptlevel to ensure the 

trailing space
Attachment #8463368 - Flags: feedback?(fred.wang) → feedback+
Posted file 10.22.txt
Usage of the mathvariant attribute in Bruce's document:

fred@debian:~/Bureau$ cat 10.22.txt | wc --lines
362
fred@debian:~/Bureau$ cat 10.22.txt | grep normal | wc --lines
340
fred@debian:~/Bureau$ cat 10.22.txt | grep bold | wc --lines
19
fred@debian:~/Bureau$ cat 10.22.txt | grep sans-serif | wc --lines
3

So shortcutting the mathvariant="normal" case seems important (However, I suspect the implicit single-char mi is even more present).
There are also 94 empty <mi>'s. Should we try to shortcut empty token elements too? (see also bug 1025164)
Posted patch Patch (obsolete) — Splinter Review
Try this build:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-3842a820de57/
(It includes a since-withdrawn patch involving single-char <mi> elements and &nbsp;, but it shouldn't make much of a difference)

For the most part minor improvements and rearranging.  The check whether a single character <mi> is transformable is now more efficient.

Per comment 19, it excludes empty or only whitespace tokens from the mathvariant processing.  The number of iterations that the loop undergoes will be minimal as earlier code should have compressed whitespace.  To keep it lightweight, the non-single char mi case assumes that any non-whitespace character is transformable, preventing the need to iterate over the entire string.  The inclusion of &nbsp; is deliberate.  It isn't transformable and the original string is left unaltered.
Attachment #8463368 - Attachment is obsolete: true
Attachment #8466204 - Flags: feedback?(fred.wang)
Flags: needinfo?(bruce.miller)
Posted patch Patch (obsolete) — Splinter Review
whitespace
Attachment #8466204 - Attachment is obsolete: true
Attachment #8466204 - Flags: feedback?(fred.wang)
Attachment #8466206 - Flags: feedback?(fred.wang)
Comment on attachment 8466206 [details] [diff] [review]
Patch

Review of attachment 8466206 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/generic/nsTextFrame.cpp
@@ +1979,5 @@
> +      }
> +      NS_ASSERTION(mathFontStyle->mMathVariant == NS_MATHML_MATHVARIANT_NONE ||
> +                   (mathFontStyle->mFont.style == NS_FONT_STYLE_NORMAL &&
> +                    mathFontStyle->mFont.weight == NS_FONT_WEIGHT_NORMAL),
> +                   "This was supposed to have been set during CSS processing");

If someone does <mtext mathvariant="script" style="font-weight: bold">x</mtext> won't that raise the assertion? I don't really remember what was the "CSS processing", perhaps you should indicate to which part of the code it refers.
Attachment #8466206 - Flags: feedback?(fred.wang) → feedback+
My test builds at http://www.wg9s.com/mozilla/firefox/ now have this patch applied for testing.
(In reply to James Kitchener (:jkitch) from comment #20)
> Created attachment 8466204 [details] [diff] [review]
> Patch
> 
> Try this build:
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.
> bug@gmail.com-3842a820de57/
> (It includes a since-withdrawn patch involving single-char <mi> elements and
> &nbsp;, but it shouldn't make much of a difference)

Unfortunately, that didn't help (possibly even slower?).  But there are new INFO messages appearing about basic_code_modules.cc that may be relevant?  Here's the log:

firefox/firefox -P noprofile -safe-mode -no-remote -new-instance

(process:25733): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size == 0' failed

(firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::sm-connect after class was initialised

(firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::show-crash-dialog after class was initialised

(firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::display after class was initialised

(firefox:25733): GLib-GObject-WARNING **: Attempt to add property GnomeProgram::default-icon after class was initialised
2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /lib64/libc.so.6|
2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /lib64/libfontconfig.so.1|
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x74bfa1249e077500
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea979d8
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x67
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed460
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed440
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209240
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead5922
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398208f30
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209261
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398208f38
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x74bfa1249e077500
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead3d00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209248
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead8360
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed540
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x408f480000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x408f980000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead8368
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x179db6b120
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x408f480000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd398209240
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e90cd40
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x100000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead35c0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed590
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd3982090c8
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e90cd40
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x31
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea13e00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd3982090e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1bf
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x788
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xf1
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e9168d0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd5a0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e90cd38
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e902000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed740
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e902000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed748
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x200000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36e916148
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1bf
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed630
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed688
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadff60
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd300000003
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7278
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc300
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xd6
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x74bfa1249e077500
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed718
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea15d00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed940
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xd6
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc300
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /archive/local/src/firefox/libxul.so|
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed704
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc300
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd389ed5d38
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed870
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed957
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed958
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd381fdc270
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xa6eadd550
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea01550
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b120
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x100000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd5a0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x4029000000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd590
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xe0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b040
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed7a0
2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: |
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eadd5a0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1000000018
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0xb3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff00000002
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eae2000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37d800000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b200
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x200
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x100
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea13e00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea13e00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37d800000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed860
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1010
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed840
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed850
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b218
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x2a
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x6
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x6
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed870
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed868
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x8000000a00000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7278
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd300000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7278
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd300000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x6
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x1
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eac7f40
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed930
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd39db6b048
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed920
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x38
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eaacb80
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea15d00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5edb68
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5edb80
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed970
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed970
2014-08-02 09:08:25: stackwalker.cc:125: INFO: Couldn't load symbols for: /archive/local/src/firefox/libmozalloc.so|
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ea15d00
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36eaacb80
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5edb40
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x4029000000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x3ff0000000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd36ead17e0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x0
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x4029000000000000
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fff0f5ed9c8
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x800000140000000d
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373c51828
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000c
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf94668
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000b
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf94648
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000007
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373c51858
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000c
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf94688
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000004
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373c51918
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000011
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd373cf4438
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000c
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf946a8
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x50000000b
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf946c8
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000005
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37a747c18
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x500000013
2014-08-02 09:08:25: basic_code_modules.cc:88: INFO: No module at 0x7fd37cf946e8
1406984968187	GMPInstallManager.simpleCheckAndInstall	INFO	Last check was: 1082 seconds ago, minimum seconds: 86400
1406984968188	GMPInstallManager.simpleCheckAndInstall	INFO	Will not check for updates.
Flags: needinfo?(bruce.miller)
(In reply to Bill Gianopoulos [:WG9s] from comment #23)
> My test builds at http://www.wg9s.com/mozilla/firefox/ now have this patch
> applied for testing.

For the record, that build gives the same behaviour as James' build;
ie. slow & lots of INFO messages.
(In reply to Bruce Miller from comment #25)
> (In reply to Bill Gianopoulos [:WG9s] from comment #23)
> > My test builds at http://www.wg9s.com/mozilla/firefox/ now have this patch
> > applied for testing.
> 
> For the record, that build gives the same behaviour as James' build;
> ie. slow & lots of INFO messages.

Well, it's the same patch so I wouls expect the same results, unless one of the other patches included in my builds make it even slower (like the stretch one for example).
Here are the <mi> elements in Bruce's document.

2667 over 3094 <mi>'s are single latin & greek letters that need to be remapped, so the current patch won't really help here. However, I guess if the italic Mathematical Alphanumeric Symbols are used in the document by LaTeXML, the patch will avoid to do the remapping and make this fast...

I think we should probably follow a fast path when rebuilding the text run for this ubiquitous case, perhaps using some kind of cache.
Try this:
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-a26d64738ab1

This introduces caching for length 1 TextRuns.

Run this build using a profile you don't care about (add -p to the shortcut/launch command).  It leaks and triggers a fatal assert on shutdown in debug builds.  I'm holding off fixing these problems until I know if the patch is worthwhile.
(The patch is here: https://hg.mozilla.org/try/rev/362f92c08877 , but it needs tidying up.)


I've tried running the test page under a profiler, but I'm not sure I can trust the results.  The profiler seems to blame everything on  nsMathMLChar::SetFontFamily and the methods that call it.  Specifically the hot code is apparently the copying and testing for equality of FontFamilyLists within nsFont objects.

The problem is that SetFontFamily seems only to be triggered by <mo> elements, which shouldn't call the MathMLTextRunFactory after the ssty feature setting code was separated out in the previous patch.
Flags: needinfo?(bruce.miller)
(In reply to James Kitchener from comment #28)
> I've tried running the test page under a profiler, but I'm not sure I can
> trust the results.  The profiler seems to blame everything on 
> nsMathMLChar::SetFontFamily and the methods that call it.  Specifically the
> hot code is apparently the copying and testing for equality of
> FontFamilyLists within nsFont objects.
> 
> The problem is that SetFontFamily seems only to be triggered by <mo>
> elements, which shouldn't call the MathMLTextRunFactory after the ssty
> feature setting code was separated out in the previous patch.

Thanks. I think this is a separate perf problem with <mo> operators that is intended to be handled in bug 1009582.
Possibly a little faster (40secs) but definitely not "normal".

I'm wondering what it might be about my system that causes it to be
so slow on whatever the modern Gecko is doing differently.
Apparently, you guys are not seeing much or any slowdown?
I see some other folks grousing about Firefox 28 being slow in general,
but I doubt they're even looking at MathML; maybe it isn't even completely
specific to MathML?
Flags: needinfo?(bruce.miller)
(In reply to Bruce Miller from comment #30)
> Possibly a little faster (40secs) but definitely not "normal".
> 
> I'm wondering what it might be about my system that causes it to be
> so slow on whatever the modern Gecko is doing differently.
> Apparently, you guys are not seeing much or any slowdown?

No, the page definitely does not take more than a few seconds to load for me.

> I see some other folks grousing about Firefox 28 being slow in general,
> but I doubt they're even looking at MathML; maybe it isn't even completely
> specific to MathML?

Well, here the patch that disabled mathvariant fixed the problem, so that's necessarily something here. Perhaps a gfx issue... I know that Fedora has specific build config and obviously Windows uses different graphic libraries. Karl may know more about that.

[An option would be to disable the math italic remapping conditionally, at build time or using a preference. The CSS italic is already used as a fallback when math italic glyphs are missing. However, that will definitely change the rendering of italic variable...]

(In reply to James Kitchener from comment #28)

> (The patch is here: https://hg.mozilla.org/try/rev/362f92c08877 , but it
> needs tidying up.)

I can't access it...
Flags: needinfo?(karlt)
Posted patch Rough caching attempt (obsolete) — Splinter Review
(In reply to Frédéric Wang (:fredw) from comment #31)
> > (The patch is here: https://hg.mozilla.org/try/rev/362f92c08877 , but it
> > needs tidying up.)
> 
> I can't access it...

Attached.  No effort has been made to tidy it up, and I have some doubts regarding the potential for false positives and false negatives.
Comment on attachment 8469941 [details] [diff] [review]
Rough caching attempt

Review of attachment 8469941 [details] [diff] [review]:
-----------------------------------------------------------------

::: layout/generic/MathMLTextRunFactory.cpp
@@ +632,5 @@
>    nsRefPtr<gfxFontGroup> newFontGroup = aFontGroup->Copy(&fontStyle);
>    return newFontGroup.forget();
>  }
>  
> +#define TEXTRUN_CACHE_SIZE 16

fred@debian:~/Bureau$ cat 10.22 | uniq | grep -v mathvariant | wc --lines
36

So Bruce's document will exceed cache size. 40s is already a 33% improvement over 60s. I wonder if we get better result with a larger limit (something like 26 * 2 letters?).

Also, at some point the mathvariant="normal" optimization might become important. I don't know if that was included in the latest build.
Posted patch Rough caching attempt (obsolete) — Splinter Review
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-f8d4802ff205

The cache is now a 52 entry hashtable.  The earlier warning about using a profile you don't care about still applies.
Attachment #8469941 - Attachment is obsolete: true
Try the build  from comment 34.
Flags: needinfo?(bruce.miller)
> Created attachment 8470387 [details] [diff] [review]
> Rough caching attempt
> 
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.
> bug@gmail.com-f8d4802ff205

Nope, didn't really help; still about 45secs.(In reply to James Kitchener from comment #34)
Flags: needinfo?(bruce.miller)
(In reply to Bruce Miller from comment #30)
> I'm wondering what it might be about my system that causes it to be
> so slow on whatever the modern Gecko is doing differently.
> Apparently, you guys are not seeing much or any slowdown?

Yes.  It is up to about 10 seconds here, but it is a little inconsistent due
to times for network response.

To remove the network effect use Ctrl+- and Ctrl+= to resize larger and
smaller.  This should test the rendering without the network effects.

Please also check http://www.wikipedia.org/ which should take no more than a
couple of seconds.  It may be faster when resized to a size that has been
drawn before, due to caching.

We've had some absurdly slow responses from fontconfig before due to some
files having timestamps in the future and so caches are always out of date.
Please run "fc-cache -v" and report whether there are any lines that do not
match any of these:

 ": skipping, existing cache is valid"
 ": not cleaning unwritable cache directory"
 ": cleaning cache directory"
 ": succeeded"
Flags: needinfo?(karlt)
One thing I notice is that MathMLTextRunFactory::RebuildTextRun() is creating a new gfxFontGroup for each text run.  That misses out on caching of font selection, usually provided by nsDeviceContext::GetMetricsFor().

http://hg.mozilla.org/mozilla-central/annotate/6a7be7376caa/layout/generic/MathMLTextRunFactory.cpp#l703
http://hg.mozilla.org/mozilla-central/annotate/6a7be7376caa/gfx/src/nsDeviceContext.cpp#l261
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-430656ceccbc

This skips the creation of a new gfxFontGroup.  It doesn't include the other patches.

Depending on your fonts it may not render italics/bold, but I'm more concerned about rendering speed.
Flags: needinfo?(bruce.miller)
(In reply to Karl Tomlinson (:karlt) from comment #37)
> We've had some absurdly slow responses from fontconfig before due to some
> files having timestamps in the future and so caches are always out of date.
> Please run "fc-cache -v" and report whether there are any lines that do not
> match any of these:
> 
>  ": skipping, existing cache is valid"
>  ": not cleaning unwritable cache directory"
>  ": cleaning cache directory"
>  ": succeeded"

I'm getting:
> fc-cache -v | grep -v 'skipping, existing cache is valid' | grep -v 'not cleaning unwritable'
/usr/local/share/fonts: skipping, no such directory
/home/bruce/.local/share/fonts: skipping, no such directory
/home/bruce/.fonts: skipping, no such directory
Re-scanning /usr/share/fonts: caching, new cache contents: 0 fonts, 238 dirs
Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3 dirs
Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts, 2 dirs
Re-scanning /usr/share/fonts/iso8859-2: caching, new cache contents: 0 fonts, 3 dirs
Re-scanning /usr/share/fonts/japanese: caching, new cache contents: 0 fonts, 1 dirs
Re-scanning /usr/share/fonts/sazanami: caching, new cache contents: 0 fonts, 2 dirs
/home/bruce/.cache/fontconfig: cleaning cache directory
/home/bruce/.fontconfig: cleaning cache directory
fc-cache: succeeded

Don't know much about what that means, or why it's re-scanning those directories.
Flags: needinfo?(bruce.miller)
(In reply to James Kitchener from comment #39)
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.
> bug@gmail.com-430656ceccbc
> 
> This skips the creation of a new gfxFontGroup.  It doesn't include the other
> patches.


Bingo! That seems to be the problem: your patch brought it down to around 7-8 seconds!!

It could be that the other optimizations you were looking at will show up
now that the main slowdown is solved, but this appears to be the main issue.
Thanks!!

> Depending on your fonts it may not render italics/bold, but I'm more
> concerned about rendering speed.

I seem to be seeing them all...

(sorry for the delay in testing)
Posted patch Patch allowing font caching (obsolete) — Splinter Review
This fetches the gfxFontGroup objects from whatever is responsible for caching them.

This supersedes the other two patches.  Debugging/profiling indicates the MathMLTextRunFactory related code isn't run frequently enough for the streamlining patch to be useful and the attempt at caching TextRuns is very nasty.

If you could please confirm that the approach works, I'll flag this for review.
https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.bug@gmail.com-c6461094d22e

I'm inclined to blame much of the remaining slowness on bug 1009582, as my profiler isn't highlighting any other issues.
Assignee: nobody → jkitch.bug
Attachment #8466206 - Attachment is obsolete: true
Attachment #8470387 - Attachment is obsolete: true
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Flags: needinfo?(bruce.miller)
(In reply to James Kitchener from comment #42)
> Created attachment 8475128 [details] [diff] [review]
> This supersedes the other two patches.  Debugging/profiling indicates the
> MathMLTextRunFactory related code isn't run frequently enough for the
> streamlining patch to be useful and the attempt at caching TextRuns is very
> nasty.

I think skipping the MathMLTextRunFactory stuff when mathvariant="normal" is easy to do, though.

> I'm inclined to blame much of the remaining slowness on bug 1009582, as my
> profiler isn't highlighting any other issues.

@Bruce: can you also try your test page with all the <mo>'s replaced by <mtext>'s? This will allow to ignore potential slowness due to bug 1009582.
(In reply to Bruce Miller from comment #40)
> Re-scanning /usr/share/fonts: caching, new cache contents: 0 fonts, 238 dirs
> Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3
> dirs
> Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts,
> 2 dirs
> Re-scanning /usr/share/fonts/iso8859-2: caching, new cache contents: 0
> fonts, 3 dirs
> Re-scanning /usr/share/fonts/japanese: caching, new cache contents: 0 fonts,
> 1 dirs
> Re-scanning /usr/share/fonts/sazanami: caching, new cache contents: 0 fonts,
> 2 dirs

This would be slowing down the browser, even for pages without MathML.

Check each directory with "ls -lart" for files or dirs with funny timestamps.
(In reply to James Kitchener from comment #42)
> Created attachment 8475128 [details] [diff] [review]
> Patch allowing font caching
> 
> This fetches the gfxFontGroup objects from whatever is responsible for
> caching them.
> 
> This supersedes the other two patches.  Debugging/profiling indicates the
> MathMLTextRunFactory related code isn't run frequently enough for the
> streamlining patch to be useful and the attempt at caching TextRuns is very
> nasty.
> 
> If you could please confirm that the approach works, I'll flag this for
> review.
> https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/jkitch.
> bug@gmail.com-c6461094d22e
> 
> I'm inclined to blame much of the remaining slowness on bug 1009582, as my
> profiler isn't highlighting any other issues.

When you do get a review ready patch please also post a diff -w.  This is one of those cases where it would be helpful.
(In reply to Frédéric Wang (:fredw) from comment #43)
> @Bruce: can you also try your test page with all the <mo>'s replaced by
> <mtext>'s? This will allow to ignore potential slowness due to bug 1009582.

Making a local copy of the page (& dependencies) and re-running as-is took around 6 secs (removing network effects?);
Replacing all the <mo>'s with <mtext>'s reduced that to around 2-3 secs, so there's indeed
still a big (percentage-wise) potential improvement.  Doesn't look as good, though! :>
Flags: needinfo?(bruce.miller)
(In reply to Karl Tomlinson (:karlt) from comment #44)
> (In reply to Bruce Miller from comment #40)
> > Re-scanning /usr/share/fonts: caching, new cache contents: 0 fonts, 238 dirs
> > Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3
> > dirs
> > Re-scanning /usr/share/fonts/default: caching, new cache contents: 0 fonts,
> > 2 dirs
> > Re-scanning /usr/share/fonts/iso8859-2: caching, new cache contents: 0
> > fonts, 3 dirs
> > Re-scanning /usr/share/fonts/japanese: caching, new cache contents: 0 fonts,
> > 1 dirs
> > Re-scanning /usr/share/fonts/sazanami: caching, new cache contents: 0 fonts,
> > 2 dirs
> 
> This would be slowing down the browser, even for pages without MathML.
> 
> Check each directory with "ls -lart" for files or dirs with funny timestamps.

Nothing that jumps out at me; no future dates, for example.

Note that I ran that as non-root; looking at the man page suggests that I ought to
run it, probably as root, with the -f and maybe -r options, to completely refresh the caches?
Even so, I think I'll wait till we sort out the current issue, so as not to throw off the comparisons.
@Bruce: so did you reply positively to James' comment 42? i.e. does his last patch still fixes the issue?
Flags: needinfo?(bruce.miller)
Yes indeed, my comment #45 was replying to both your #43 and James' #42 using the build linked to from there.
Flags: needinfo?(bruce.miller)
(In reply to James Kitchener from comment #42)
> Created attachment 8475128 [details] [diff] [review]
> Patch allowing font caching

Just a heads-up that this patch has bit-rotted slightly.  Fix is to replace both instances of -moz-font-feature-settings with font-feature-settings in the patch file.
BTW.  I am now including this patch in my nightly builds with other MathML enhancements available here http://www.wg9s.com/mozilla/firefox/
Posted patch diff -w (obsolete) — Splinter Review
Patch with diff -w for convenience.
Posted patch Patch allowing font caching (obsolete) — Splinter Review
(See comment 52 for a whitespace ignoring diff of this patch).

Previously the MathMLTextRunFactory created a new gfxFontGroup every time it was called, preventing font caching from working properly.  The attached patch now performs font manipulation on nsFont objects, allowing gfxFontGroup caching to work properly.

The remaining changes (rephrasing a comment and a slight reduction in the number of times the MathMLTextRunFactory is created) are minor.
Attachment #8475128 - Attachment is obsolete: true
Attachment #8477338 - Flags: review?(roc)
whitespace fix.
Attachment #8477338 - Attachment is obsolete: true
Attachment #8477338 - Flags: review?(roc)
Attachment #8477341 - Flags: review?(roc)
Comment on attachment 8477341 [details] [diff] [review]
Patch allowing font caching

Review of attachment 8477341 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!!!
Attachment #8477341 - Flags: review?(roc) → review+
Attachment #8477334 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/165df837579e
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
We forgot about comment 12 here. I think we should try to make a talos test from a page with many <mi>'s and mathvariant's (and without stretchy/large op since that's a separate problem). 

https://wiki.mozilla.org/Buildbot/Talos#Adding_a_new_test
Flags: needinfo?(ra092767)
Flags: needinfo?(jkitch.bug)
Frédéric,

I will try it and sorry for the delay.
Flags: needinfo?(ra092767)
(In reply to Bruce Miller from comment #47)
> Nothing that jumps out at me; no future dates, for example.
> 
> Note that I ran that as non-root; looking at the man page suggests that I
> ought to
> run it, probably as root, with the -f and maybe -r options, to completely
> refresh the caches?
> Even so, I think I'll wait till we sort out the current issue, so as not to
> throw off the comparisons.

Bill recalled that comment during the MathML meeting... Did you try to refresh your font cache and to run the test again with a recent nightly build? Just to see whether that improves your last result...
Flags: needinfo?(bruce.miller)
How complicated does the test need to be?

Would several thousand <mi> elements, with randomised alphanumeric content and random mathvariant attributes be sufficient?
Flags: needinfo?(jkitch.bug)
(In reply to James Kitchener from comment #62)
> How complicated does the test need to be?
> 
> Would several thousand <mi> elements, with randomised alphanumeric content
> and random mathvariant attributes be sufficient?

Yes, I think so since the bottleneck was the font caching in the MathMLTextRunFactory, and no other MathML constructions were actually involved.
(In reply to Frédéric Wang (:fredw) from comment #61)
> (In reply to Bruce Miller from comment #47)
> > Nothing that jumps out at me; no future dates, for example.
> > 
> > Note that I ran that as non-root; looking at the man page suggests that I
> > ought to
> > run it, probably as root, with the -f and maybe -r options, to completely
> > refresh the caches?
> > Even so, I think I'll wait till we sort out the current issue, so as not to
> > throw off the comparisons.
> 
> Bill recalled that comment during the MathML meeting... Did you try to
> refresh your font cache and to run the test again with a recent nightly
> build? Just to see whether that improves your last result...

I did try to rebuild the cache, but I don't think it worked: I still get messages about Re-scanning.
Poking around at it, it looks like the directories that cause it to rescan
 * contain other directories
 * contain gzipped files, like b10.pcf.gz (rather than plain .ttf, .pcf, etc)
In those cases, it says soemthing like:
Re-scanning /usr/share/fonts/KOI8-R: caching, new cache contents: 0 fonts, 3 dirs
ie. it ends up with "0 fonts".  Curiously, fc-list *does* list the gzipped fonts in those
directories.

Any ideas on how to eliminate the re-scan?  (It should be clear by now, I'm clueless on font caches!)
Flags: needinfo?(bruce.miller)
Duplicate of this bug: 1061349
(In reply to Bruce Miller from comment #64)
> Any ideas on how to eliminate the re-scan?  (It should be clear by now, I'm
> clueless on font caches!)

I don't know what is happening there.  Perhaps running fc-cache with FC_DEBUG=432 in the environment might provide some clues, or use different values for less verbosity.

http://www.freedesktop.org/software/fontconfig/fontconfig-user.html#DEBUG

If this is on an old OS distribution, then there may be a fontconfig bug that has been fixed in more recent versions.
You need to log in before you can comment on or make changes to this bug.