Davide P. Cervone
unread,Feb 1, 2015, 3:27:19 PM2/1/15Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Sign in to report message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to mathja...@googlegroups.com
The issue here is not really the complexity of the mathematics, it is the fact that stretchy delimiters are created from multiple (small) pieces, and that the larger they are, the more pieces are needed. In your case, after the first 5 or so square roots, the remaining ones are formed from multiple characters for the vertical line. It is the fact that the equation uses so many of those lines (and that they are so long) that is the real cause of the long processing time.
MathJax currently has four different output modes: HTML-CSS, SVG, NativeMML, and the new CommonHTML. Of these, only HTML-CSS uses multiple pieces for the delimiters. Switching to SVG output, for example, processed the output much quicker. Of course, the timing will depend on the speed of your computer, the amount of memory available, what else is running on the computer, the operating system used, and other factors, but here are some results from my setup to give an idea of the relative speeds of the various output forms using your example:
In Safari:
HTML-CSS: 7 seconds to process, 10 more to display (17 total)
SVG: .2 seconds
CommonHTML: .05 seconds
NativeMML: .02 seconds
In Firefox:
HTML-CSS 13 seconds to process, 31 more to display (44 total)
SVG: .25 seconds
CommonHTML: .1 seconds
NativeMML: .04 seconds to process, 9 seconds to display
So you can see that the HTML-CSS output (that uses multiple characters for each square root) is substantially slower than the other forms. The results also take a long time to display on screen as the layout is complex and it takes the browser longer to get the display worked out than it takes MathJax to specify the DOM.
The SVG output uses a single stretched joining character between the two end characters (so three in all), while CommonHTML uses only one character stretched (for rather bad results). Safari is in general twice as fast as Firefox, and its NativeMML appears to use a single stretched character, not multiple ones. The long delay in Firefox's NativeMML suggests that it also uses multiple characters for the stretched glyph internally.
MathJax's HTML-CSS mode does have a parameter that controls the maximum number of characters that it will use when creating a stretchy character. By default, it is 1000, but if you set this to 20, for example, then HTML-CSS output becomes
Safari HTML-CSS: 1.7 seconds, 2.3 more to display (4 total)
Firefox HTML-CSS: 2.5 seconds, 2.5 more to display (5 total)
But if you do this, the delimiters don't stretch as far as they should. Moreover, HTML-CSS uses multiple characters for the line over the square root as well, and these become dashed lines if not enough characters are used. So reducing this number too far can damage the output. But you certainly could limit it to something smaller than the default. To do so, use
<script type="tet/x-mathjax-config">
MathJax.Hub.Register.StartupHook("HTML-CSS Jax Ready",function () {
MathJax.OutputJax["HTML-CSS"].maxStretchyParts = 100; // or whatever value you want
});
</script>
before the script that loads MathJax.js initially. Alternatively, you could switch to SVG output for now until the CommonHTML output matures.
Finally, since you brought up KaTeX, I measured that as well on your expression:
Safari KaTeX: 13 seconds
Firefox KaTeX: 56 seconds
Since KaTeX implements the TeX display pipeline, it uses multiple character stretchy delimiters as well, and so gives results comparable to MathJax's HTML-CSS output in this case.
I don't think that limiting the complexity of the mathematics, or the length of the expression as a TeX string, or the nesting level, or solutions of that sort are the right approach, here. The math can be processed relatively quickly, as is shown by the SVG and CommonHTML output. It is building the stretchy delimiters that is causing the trouble, and that is where the solution has to lie.
Davide