You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using heap profiling on my ~100K document,
I see Chrome heap dump usage mainly consists of 50~60MB of DOM and ~40MB of CodeMirror.Lines arranged in a b-tree. It's similar with checking and without.
One would expect the partial DOM to be much smaller than CodeMirror's full b-tree, but this is a math-heavy document. I've tried switching MathJax to SVG output with similar results. But actually, it's sensitive to viewport. Scrolling to a math-free portion and taking a snapshot, there's still similar amount of DOM but it's in small detached fragements.
Can we do better?
Without math rendering, there is only 9MB of DOM and 360KB of CodeMirror DOM!
Can we somehow avoid keeping storing off-screen math in rendered DOM form?
KaTeX might help. Not sure its math output is much cheaper, but it might be fast enough to call render() from CM's renderLine callback, materializing it only for visible part.
If that helps, in principle we could use MathJax to render math to HTML strings, keep them in some hash, and replace $...$->HTML on renderLine.
The text was updated successfully, but these errors were encountered:
Data point: saved mhtml of that page (HTML-CSS, Chrome) is "only" 3.2M, and SVG is measly 163K!
(SVG is much smaller due to <defs>/<use>.)
So yes, storing off-screen math as HTML strings could save memory.
[The mhtml dump of course under-estimates actual DOM usage, e.g. doesn't reflect event handlers. But it does reflect what is ideally achievable by storing strings instead of detached DOM.]
This SVG number doesn't match heap profiler numbers at all.
I just re-tested (with editor.setOption('viewportMargin', Infinity)) and yes, it says 43M memory for DOM. I guess it really creates deep copies for <use>? (it's not just double-counting - actual process memory is similar to tab with HTML-CSS.)
(Separate thought: are no longer used <defs> ever garbage-collected? I'm almost sure not.)
[spin off from https://github.com/cben/mathdown/issues/56#issuecomment-108872386]
Using heap profiling on my ~100K document,
I see Chrome heap dump usage mainly consists of 50~60MB of DOM and ~40MB of CodeMirror.Lines arranged in a b-tree. It's similar with checking and without.
One would expect the partial DOM to be much smaller than CodeMirror's full b-tree, but this is a math-heavy document. I've tried switching MathJax to SVG output with similar results. But actually, it's sensitive to viewport. Scrolling to a math-free portion and taking a snapshot, there's still similar amount of DOM but it's in small detached fragements.
Can we do better?
Without math rendering, there is only 9MB of DOM and 360KB of CodeMirror DOM!
Can we somehow avoid keeping storing off-screen math in rendered DOM form?
KaTeX might help. Not sure its math output is much cheaper, but it might be fast enough to call render() from CM's
renderLine
callback, materializing it only for visible part.If that helps, in principle we could use MathJax to render math to HTML strings, keep them in some hash, and replace$...$ ->HTML on
renderLine
.The text was updated successfully, but these errors were encountered: