IE8 / IE9 reflow performance
Sean Hogan
I had a couple of interesting results today.
I wanted a page that simply tests browser reflow performance, without
using element dimension lookups - I was thinking that this might be a
good example to add to the issue report I've made with Microsoft. You
can see what I came up with at
http://playground.meekostuff.net/MathJax-test/shogun70/master/layout-demo3.html
The test merely
- inserts new content (a MathJax generated equation HTML) into the page
- yields to the browser (via setTImeout)
- records a timestamp
- starts the process again.
When the script yields to the browser you would expect a page reflow /
repaint operation to proceed, blocking any more scripts until done.
As you would expect, Firefox, Chrome, Safari run pretty fast, with the
reflow operation being around the same as the yield time (which is 15ms)
which means it might be less.
In IE8 the browser slows down considerably as more content is added to
the page.
You could try this with
http://playground.meekostuff.net/MathJax-test/shogun70/master/layout-demo3.html?equation=lorenz&count=100&run=Run
For me, the page updates start at around 15ms, but by equation #100 they
are around 700ms.
The page can also use a low quality equation HTML snippet. For
comparison, try
http://playground.meekostuff.net/MathJax-test/shogun70/master/layout-demo3.html?equation=lorenz2&count=100&run=Run
This gives a surprising result where the page updates barely slow, so
that equation #100 is around 30ms. The element count is probably less
than half, but it must be something about removing a lot of the extra
positioning styles.
Another surprise is IE9 performance. Both the above tests run fast on
IE9 - equation #100 is around 50ms and 30ms respectively.
I'm not sure what to make of these results, and I'm not even sure that
they have any relevance to MathJax at this stage. I'm just posting this
for the record, but if gives you any ideas or if you want me to add
another test then feel free to reply.
Sean
Robert Miner
How did you produce the low-quality markup? What was the algorithm?
How far did you go with selectively adding back in some of the markup
you removed to see where the performance tanks? For example, if you
leave one or two spans in with positioning code, do we still see
processing time blow up in IE8?
I know you and others have floated the idea of doing an initial, fast
"low-quality" rendering, and then filling in the attributes for high
quality layout in a second pass, perhaps tied to viewport changes. If
one leaves the MathJax generated structure intact, and just removes the
positioning CSS, do we still see the fast IE8 times? Looking at the
code in your test page, it looks like you've removed not only the
positioning CSS, but also the spans they were set on when those spans
have no other purpose.
--Robert
Sean Hogan
> Intriguing result, Sean. You've clearly found the bottleneck in IE.
>
> How did you produce the low-quality markup? What was the algorithm?
1. start with MathJax HTML output
2. remove all IDs, styles, and other attributes except for mathml
classes (math, mi, mo, etc)
3. remove all spans that won't be necessary for the final layout (in
general this just leaves the pseudo-MathML)
4. add minimum styles to make the markup readable
A bit more styling would be necessary for this example to look okay on
older IE versions.
I'm not able to say whether this approach would produce reasonable
output for all math content.
> How far did you go with selectively adding back in some of the markup
> you removed to see where the performance tanks? For example, if you
> leave one or two spans in with positioning code, do we still see
> processing time blow up in IE8?
>
I'll add in a couple of intermediate markup examples.
Sean Hogan
http://playground.meekostuff.net/MathJax-test/shogun70/master/layout-demo3.html
The samples are (all for Lorenz equations):
1. IE8 generated - IE8 usually requires more elements than the other
major browsers (in this case the element count is 98).
2. Firefox generated - (element count is 86)
3. Minimal styles - start with #2 and remove any styles that aren't
necessary to keep the equation readable (86)
4. No spreaders + Min styles - MathJax uses zero width, fixed height
empty spans to enforce min-height for parts of the equation. This sample
starts with #4 and removes those spreader spans. (70)
5. Minimal elements - start with #2 and remove any elements and styles
that aren't necessary to keep the equation readable. Ideally this should
only leave the HTML elements that map to MathML elements. (50)
6. Blocky + Min elements - start with #5 and add "display: block" styles
to all appropriate spans.
No surprises in the IE8 results - as complexity is removed from the DOM
the performance improves.
Samples #1 & #2 have similar performance.
Samples #3 & #4 cull styles and have similar performance.
Samples #5 & #6 reduce the depth of the DOM (culling intermediate
elements) and have similar performance.
In my previous email I suggested that IE9 had surprisingly good
performance for sample #1 in this test, even when inserting 100
equations. After another look at IE9's MathJax rendering performance I
would say the results are about as expected - IE9's MathJax rendering is
slow, but it doesn't degrade badly as IE8 does when rendering several
equations.
What these results suggest to me is that if we introduce a low-quality
mode (that doesn't require and dimension lookups), then on IE8 it will
need to have the simplest HTML possible, otherwise we will still see
unacceptable performance degradation on large pages.
I'll write up a performance analysis, including options like a
low-quality mode, and add it to the wiki.
Sean
On 18/12/10 2:51 AM, Robert Miner wrote:
Sean Hogan
and is investigating, see:
https://connect.microsoft.com/IE/feedback/details/623970/dimension-lookups-offsetwidth-height-etc-are-very-slow