2.5 much slower than 2.4

[kennytilton]

Hi, I am seeing performance drastically slower on http://tiltonsalgebra.com/#mathpaper. (But that has now been reverted to 2.4 and will not manifest the problem.)

That page normally renders instantly. Now I watch each expression and virtual keypad key render one at a time, about a quarter second each.

This is my HTML:

<script type="text/javascript" src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"> </script>

Pinging the cdn I get 162.159.241.204

Same slowdown as well in my development environment. Production (the URL above) has not been touched in a couple of weeks.

I have tested on Chrome, FireFox, (on Windows) and Safari on a MacBook Pro. cache has been cleared. All show same performance issue.

Switching to 2.4-latest has restored the performance.

I see something about a new preview option in the doc. I will try turning that off.

[kennytilton]

the fast preview option broke display completely.

I should disclose that I have quite the elaborate process for MathJax, using the mathjax queue and listeners to detect when MJ has finished processing the LaTex and then adjusting surrounding dimensions to suit the rendered size.

Also, this is a single-page qooxdoo app where all JS is generated on the server and executed via AJAX (so you cannot just inspect my page source).

If no one else reports this slowdown we can close this.

[dpvc]

Did you try v2.5 but with the Fast Preview disabled? The fast preview turns itself off after the initial display, so I don't see how it can be responsible for the issues you describe in editing. There is a new (short) pause between input processing and output processing to allow the message area to update, so you might try turning that off and see if that is the culprit. Try setting

MathJax.Hub.processSectionDelay = 0;

and see if that helps.

Is it possible for you to set up a page that uses v2.5 for us to look at? It is not really possible to investigate the issue without that, given your complex setting.

[kennytilton]

Adding that snippet that turned of fast preview stopped all rendering. That is probably a good clue. If I need to get to 2.5 I will probably put that back in and then see what broke in my process.

I did suspect that update delay, but setting it to 0 did not help. Thx for the suggestion, tho.

[kennytilton]

Is this right?

MathJax.Hub.updateSectionDelay = 0;

I was curious as to the default delay and printing out that property says undefined...OK, good for console symbol completion, I found: MathJax.Hub.processSectionDelay

That works! Thx!

[dpvc]

Sorry, my fault. You are right, it is processSectionDelay. I mistyped it, but will edit the message above.

When you said that works, do you mean that that made your editor work at the expected speed again in v2.5?

[kennytilton]

Yes, the expected speed is back and I imagine it is even faster thx to the
2.5 improvements. That is not clear because speed was already great, but I
sense improvement.

Thx a ton! I am on 2.5 now in development now and will let it go out in my
next release unless something turns up (but I have hit all the
functionality quickly and everything works fine).

Thx again, kt

[dpvc]

Great to hear! Glad that that was all it was. We will keep that in mind if others report similar issues, and it probably needs to be documented better. I suspect the default delay could also be reduced. Thanks for keeping us informed, and good luck with your project.

[itkach]

2.5 does indeed appear to be noticeably slower than 2.4, or more specifically HTML-CSS rendering appears to be slower, SVG appears to be more or less the same or maybe a bit faster in 2.5.

I am using MathJax with wiki2jax and texvc extensions to render math in Wikipedia articles in Aard 2 dictionaries. After I updated MathJax to 2.5 processing/typesetting seemed to take longer, so I've made some crude measurements to confirm, results are here:

https://gist.github.com/itkach/6b4fe43dcee763f7a12b

Setting MathJax.Hub.processSectionDelay to 0 as recommended above didn't seem to make a difference.

Test dictionaries (with few articles - Integral, Pi, Logarithm, Sine) are here:

https://www.dropbox.com/sh/hft8qjx8gqdcfx5/AADgNflbTTNj6HV0g4OCDP4La?dl=0

Dictionaries were created with https://github.com/itkach/mwscrape2slob, with HTML-CSS and SVG Mathjax configs defined here: https://github.com/itkach/mwscrape2slob/tree/00a53916143bff7ab73d57f0f310496dccd4a2e1/mathjax

To see it in action in a browser:

• install Java runtime
• download Aard 2 for Web jar file from https://github.com/itkach/aard2-web/releases/ to the same directory where test dictionaries are
• start web server with one dictionary open like this:

   java -jar aard2-web-0.5.jar enwiki.mj24.svg.slob

• Open http://127.0.0.1:8013 in a browser
• Open dev tools/JS console
• Type article title in Lookup field, for example "pi", select lookup result from the list
• Look for message in JS console logging how long did it take for MathJax to finish
• Repeat for each dictionary file

[pkra]

@itkach can you provide a simpler way to reprodce your timings?

[itkach]

can you provide a simpler way to reprodce your timings?

Here, I think this is better:

https://github.com/itkach/mathjax-perf-test (see README)

Basically just clone it with --recursive to get test html along with my MathJax repo which includes MediaWiki configs and extensions and open test html files in a browser, open dev tools and reload page, checkout master or v2.4-latest to switch between MathJax 2.5 and 2.4.

My results with this setup are in README. From these updated numbers I wouldn't call 2.5 "much" slower than 2.4, but it does appear to be somewhat slower on some content (Pi, Integral), about the same on other (Logarithm) and sometimes a bit faster (Sine). It's probably also fair to say that 30%-40% performance improvements for HTML-CSS cited at http://docs.mathjax.org/en/latest/whats-new-2.5.html didn't materialize for this content.

[pkra]

Thanks for taking the time. Those are some interesting samples. FWIW, the test does not actually time the layout process (which is what the announcement refers to) but that's not very important in this case, I think. A quick test on my machine with Chrome 39 has both versions of HTML-CSS at ~1300ms for typesetting alone -- that's not a lot to go on in either direction given a variance of ~300ms. Anyway, against the spirit of "never trust a performance test you didn't manipulate yourself" it's disappointing to see such a "normal" sample to behave differently than we had anticipated.

As mentioned in the announcement, the improvements are largest in very complex and long documents -- that was our goal and our testing was certainly skewed along those lines. Still, the way we implemented the improvement should certainly not have led to a slow down so we'll definitely take another look at those examples.

Thanks again for your feedback on this.