Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce math memory usage #35

Open
cben opened this issue Jun 4, 2015 · 2 comments
Open

Reduce math memory usage #35

cben opened this issue Jun 4, 2015 · 2 comments

Comments

@cben
Copy link
Owner

cben commented Jun 4, 2015

[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.

@cben
Copy link
Owner Author

cben commented Jun 4, 2015

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.)

@cben
Copy link
Owner Author

cben commented Jun 4, 2015

BTW, this "widget dehydration" technique, if it works at all, might be a worth impelmenting in CodeMirror itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant