Sluggish UI when long, math-heavy notebooks are open. #9757
Comments
|
Also related to #7218 i think (speed improvements should be a major benefit of mathjax 3 http://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html#improved-speed) |
|
Do you know if this slowness new in recent versions of lab?
…On Sun, Feb 7, 2021 at 9:56 AM Chris Holdgraf ***@***.***> wrote:
Also related to #7218
<#7218> i think (speed
improvements should be a major benefit of mathjax 3
http://docs.mathjax.org/en/latest/upgrading/whats-new-3.0.html#improved-speed
)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#9757 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGXUH4GSMBRDLG6G2IAU3S53H4XANCNFSM4XHVZFAQ>
.
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform (brgrange@amazon.com)
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub
|
|
@ellisonbg sorry, not sure actually: I only noticed a few days ago and since it's with material from a new course, we've been on 3.0.x since the start. So I don't have a reference point from the 2.x series, never worked on these materials last semester when using Lab 2.x. |
|
@fperez I tested your notebook out on 2.2.9, can confirm same problem with sluggishness, especially when clicking to open/close a menu. I did a bit of profiling, and the problem is pretty obvious: there's waaaay too many DOM nodes. Your example notebook renders as ~19,000 separate nodes, around ~9,500 of which are created by mathjax alone; it seems that mathjax renders every separate symbol as a separate As for why the menu performance in particular is bad, that's apparently due to the /**
* Test whether a client position lies within an element.
*
* @param element - The DOM element of interest.
*
* @param clientX - The client X coordinate of interest.
*
* @param clientY - The client Y coordinate of interest.
*
* @returns Whether the point is within the given element.
*/
export
function hitTest(element: Element, clientX: number, clientY: number): boolean {
let rect = element.getBoundingClientRect();
return (
clientX >= rect.left &&
clientX < rect.right &&
clientY >= rect.top &&
clientY < rect.bottom
);
}The call to |
|
Yeah, over on agoose77/jupyterlab-markup#14 we toyed with the idea of giving the option to delegate the actual math rendering out to a server-side cache... this would initially be far slower, and much more annoying to set up, but if cached properly, would result in many, many fewer DOM nodes, and you could use all of your domain-specific LaTeX stuff. A half-step between this would be to use the MathJax SVG output, render off-screen (maybe in an iframe) and generate |
I was also wondering if just sticking the mathjax svg output directly into a single inline I'm not 100% sure whether that's actually true or not, but I think it would be relatively simple to implement, and might be worth trying out? |
Separate from any mathjax question, it's probably also worthwhile for us to consider how we can improve
|
|
Thx so much for that debugging work @telamonian, much appreciated! I think what we're seeing is that as the tools get more robust (JLab, MathJax, JupyterBook), we're using them in ever more demanding cases, like these highly mathematical, essentially full-length interactive textbooks. I'm curious as to whether the MathJax 3.x claimed rendering speed improvements (linked above by @choldgraf) would have any impact here. My issue wasn't so much initial rendering speed and more the resulting sluggishness of the whole UI afterwards, so I don't really know if their changes (welcome as they are) would have any positive effect here... Have any of you tested MathJax 3.x already in JLab? Is it easy to try a swap, or have the APIs changed so much that even testing is a big lift? |
|
(I just published new versions of these extensions that update to MathJax 3.1 and Katex 0.12, respectively) |
I'm very interested if the extensions improve the situation at all! 👀 |
Yeah, the behavior/performance of inline SVG is sometimes a little funky, and can still get weird stuff happening, certainly between browsers. The big advantage, of course, is that CSS works.... but the biggest performance disadvantage is... CSS works. Moving almost all icons to inline SVGs has not been kind to performance... on the LSP completer, we offer Symbol icons (even have icon themes!) but Anyhow: re: generating MathJax out-of-band, perhaps better the iframe concept, it looks like it's possible to do at least the SVG output in a webworker. It's pretty short (partially because coffeescript... ahh, the memories) so a good example of prior art. Again, generating maximally one DOM node per yeah, even if we do get some of the mathjax stuff under control (which is important, given how easy it is to make them with markdown), there are a number of extensions that generate a lot of DOM. We (and other said extensions) also have a lot of CSS rules, some of which are pretty broad, yet match pretty specifically. I don't know of good tool for profiling CSS at the rule level, but it might be worth investigating, especially if it was simple for lab authors to use.
avoiding GBCR is indeed clutch. It looks like it's used in <10 places in lumino (the datagrid one is separate) and even fewer in lab core (although in one helper, it's inside a loop!). if i recall correctly, this was ironically done for performance reasons to avoid making lots and lots of event listeners in lumino vdom, as they do stack up, for sure, but they do in any virtual DOM. It certainly seems reasonable to have 1000s of file listings, though 1000s of menu items seems far less likely. I know the d3 folks figured out a bunch of this through other means, so might have some prior art. I also don't know about whether the quickly-googled alternatives have similar problems, but generally it's possible that some form of caching would work, though the various virtual DOM integrations would get complicated, and might make caching (the other approach suggested) very hard to reason about. |
|
Yes, But why do we need to call private _evtMouseMove(event: MouseEvent): void {
// Hit test the item nodes for the item under the mouse.
let index = ArrayExt.findFirstIndex(this.contentNode.children, node => {
return ElementExt.hitTest(node, event.clientX, event.clientY);
});
//...
}end up re-implementing the "mouse over" and "mouse out" events for children; there are some small benefits of this approach (children not telling parents what to do + avoiding a few event listeners more) but not worth it at such a performance hit. Fewer listeners are nice but not at a cost of firing another listener thousands times (at every single pixel the mouse moves over in the menu...). There are a few solutions we could try:
The solutions (1) and (2) would be backward-compatible and can backported to JupyterLab 3.x; I am not sure if (3a) would need to break interfaces (we need to tell the observer to observe but we could just spawn observers ad hoc - but this might come with a penalty and defeat the purpose). Solutions (3b) and (4) will require breaking changes and we would need to bump lumino major and wait for JupyterLab 4.0. @fcollonval should we discuss this one at the next performance meeting? Do we have a test case for this one?
Grace Bible Church Rugby? Gross Building Coverage Ratio? PS. this issue is also annoying for notebooks with no math at all, just a lot of content. I think that some browsers might be more severely affected than others. |
|
Instead of a hit test, could we do a node.contains test on the mouse move target? |
|
Yes, that's a great suggestion. I tried that in jupyterlab/lumino#273 but it turns out that it does not solve the issue for menu(bar) responsiveness because other operations trigger the reflow even if we eliminate My assumption that using Maybe the next step would be to try to understand which styles are expensive and cause the reflow to take so long? This introduction to performance mentions web components and BEM as possible approaches to tackle the issue but does not explain how to narrow down problematic rules. Might be worth a dive to see what tools could help us understand why layout shift takes so long (other than because there are many nodes). |
|
Analysis: I am currently focusing on the delay visible when moving mouse out of the menu and the over again (this is universal problem when the test notebook is open and affects all menus, including menu bar and context menu):
After lower than expected improvements in jupyterlab/lumino#273 and failure to eliminate this even when commenting out handlers for
The profiler does not show why those come to be - just that they follow browser-native The following experiment suggests that this might be triggered by
And this time there is no style recalculation anymore nor scheduling of it:
Now the behaviour of So why a Hit Test might schedule a style recalculation even though nothing changed in the DOM? Why does it not happen every time but just some times? Well <style>.test:hover{background:red!important}</style>This indeed restores the
While I only tested on Chromium-based browsers, I would not be surprised if other engines are affected too. |
Proposed solutionCould we add a The UX would be consistent with how native menus (both context menus and application-level menus) work in Chrome (on Ubuntu), in GNOME and I suspect in many other applications/environments: neither hover nor click works on background elements when menu is open. Firefox does a bit of both: clicks do not work on background elements when context menu is open, but hover styles do; clicks do work in Firefox though when the topbar menu is open (as do hover styles). And it be super fast regardless if the number of nodes in the DOM is 6000 or 600000. Edit: just in case if someone was wondering, setting |
|
Thanks for digging up on this one and sharing your experiment result. I'm 👍 for your proposed solution. |
|
Thanks for sharing this post in jupyterlab/benchmarks#90 and your great analysis. I also think we should go ahead with @krassowski's proposed solution. While not clearly ideal, if the code is well documented as to why we added this DIV we can always revert it if we find a better solution. @krassowski you volunteering to make this change or did you need some help? FWIW for chrome on windows, when you have a menu open (e.g. context menu) the menu closes on keypressdown so you can effectively directly click on links that seems to listen to keypressup. |
|
Alternatively: Using content-visibility:auto css on
Specification is WIP but majority of the browsers implemented it except firefox and seems like firefox doesn't have hit test style/layout recalculation issue.
Having content-visibility:auto css should also help in other common user interactions which trigger css reflow (apart from menu bar delay issue) Any cell outside of view port is considered to have 0 height because of which scroll jitters, to avoid scroll jitter we need to combine above with contain-intrinsic-height (not supported in firefox and safari) We can use place holder cells height (let's say 70px) to start with for every cell which is not in viewport and hasn't rendered yet even once. Since cells can be of varying length this constant 70px height assumption won't work well, to overcome this contain-instrinsic-height: auto 70px can be used which gets rid of 70px height assumption as soon as cell gets into viewport (for ex: because of scroll), computes its actual height and uses this newly computed height as new reference instead of 70px when it goes out of viewport. |
|
Hi all, |
|
It can be even slower when open a "New view for notebook". |
|
Coming back to this issue after some more exploration on the Lumino side and checking with latest JupyterLab 4.0.0-alpha28:
Further analysis using Searching the Chrome bug tracker I found:
Concatenating style tags: does not help Without any extensions (in dev mode) JupyterLab 4.0 has 144 style tags ( const individualStyles = [...document.querySelectorAll('style')];
const concatenated = individualStyles.map((x) => x.innerHTML).join('\n')
var style = document.createElement('style');
style.type = 'text/css';
style.innerHTML = concatenated;
document.getElementsByTagName('head')[0].appendChild(style);
individualStyles.map(x => x.remove());There may be some advantage of doing so for other performance issues, but the benefits were not seen for this specific issue. Disabling styles one by one: bingo Removal of just three style tags reduces the style re-computation time by over an order of magnitude; in 4.0.0-alpha28 these can be removed with: let styles = [...document.querySelectorAll('style')];
styles.slice(104, 105).map(x => x.remove());
styles.slice(119, 121).map(x => x.remove());the ordering of style tags will vary between versions (and possibly extensions installed/plugins disabled). These are two style sheets from MathJax and styles for We already know that the trigger is .MathJax_Hover_Arrow:hover span {background-color: #CCC!important}and .MathJax_MenuClose:hover span {background-color: #CCC!important}and .jp-RunningSessions-shutdownAll.jp-mod-styled:hover > span {
background-color: var(--jp-layout-color2);
}
.jp-RunningSessions-shutdownAll.jp-mod-styled.jp-mod-disabled:hover > span {
background: none;
}Rules which include .MathJax_MenuClose:hover {color: white!important; border: 2px solid #CCC!important}
.MathJax_MenuClose:hover:focus {outline: none}
.MathJax_Hover_Arrow:hover {color: white!important; border: 2px solid #CCC!important}
.jp-RunningSessions-item:hover {
background-color: var(--jp-layout-color2);
}
.jp-RunningSessions-item:not(:hover) .jp-RunningSessions-itemShutdown {
visibility: hidden;
}
.jp-RunningSessions-sectionList
.jp-RunningSessions-item
.jp-Button.jp-RunningSessions-itemShutdown:hover {
background: var(--jp-layout-color3);
}Note that it does not matter if The With this new knowledge I was able to create a minimal reproducer which works regardless of notebook windowing, which is a notebook with a single cell containing the following code and its output: from IPython.display import HTML
display(HTML(
''.join([
'<span>x</span>'
for _ in range(50000)
])
))Recalculating style on hover takes ~350 ms for me with all the styles and only ~8ms with the styles mentioned above removed. This highlights that the default MathJax styles compromise performance (due to a potential Chromium/blink performance issue) even if no MathJax expressions are on the page. Note: creating a large SVG with 50k nodes in itself does NOT recreate the problem: from IPython.display import HTML
from random import random
display(HTML(
'<svg>' +
''.join([
f'<circle cx="{random() * 100}" cy="{random() * 100}" r="{random() * 10}" stroke="black" stroke-width="1" fill="red" />'
for _ in range(50000)
]) +
'</svg>'
))Taken together, this looks similar to a bug in Chromium: 1248496: Pesudo hover on parent element affects all the child elements if the child contains the form element, but from a different code path. Indeed in the above I was able to modify the reproducer from Chrome issue 1248496 to demonstrate the problem we are hitting: <html>
<head>
<style>
.editIcon {
opacity: 0;
}
.container:hover .editIcon {
opacity: 1;
}
.unused-class:hover > span {
background: red;
}
</style>
</head>
<body>
<div class="container" id="test">
<div>
<div class="editIcon">##</div>
</div>
</div>
</body>
<script>
let container = document.getElementById('test')
for (let i = 0; i< 100000; i++) {
let newDiv = document.createElement('div')
newDiv.appendChild(document.createTextNode(`sampleDiv ${i+1}`));
let newInput = document.createElement('span');
newInput.innerHTML = 'x';
newDiv.appendChild(newInput);
container.appendChild(newDiv);
}
</script>
</html>After recording performance profile when hovering over |
|
There are also rules causing sluggish UI in presence of many
|
|
As I indicated in #13159, huge, huge ❤️ to @krassowski for this deep-dive into the problem and providing a fix. Many will benefit from these improvements, looking forward to testing it soon! |
|
Thanks! Just to clarify this issue was not fully resolved by #13159 since:
So while we did make a lot of progress, the issue got closed because we track the remaining tasks elsewhere, not because the problem is fully solved. One final thing we could do to prevent specifically math-heavy notebooks from degrading performance is to use MathJax 3 in JupyterLab 4.0 - does anyone here have any comments (i.e. tried out MathJax 3 as a replacement as suggested earlier and encountered any issues or not)? |
|
FYI, MathJax is now doing prereleases of mathjax version 4.0. Mathjax 4.0 implements the linebreaking that we identified as a possible compatibility issue at #7218. See mathjax/MathJax#2312 (comment) for more discussion about the linebreaking and the release notes for mathjax 4.0a1. As for performance issues, MathJax 4.0 release notes say that it does some font load asynchronously now, which may speed up the initial loading. |
|
Comparing MathJax2 vs MathJax3 with the
Times given in milliseconds IQM [Q1 – Q3] *) proxy for resizing main area widgets This effect appears entirely attributable to reduction in number of DOM nodes; when running benchmarks with 50k div, span and svg nodes and no math expressions I only see small, likely spurious, differences:
As for the alternative, Katex, it does not seem as promising as MathJax 3, but is still faster than MathJax 2:
|
Description
We're noticing the UI in Lab 3.0.x (x ~ 5-7) getting sluggish (slow menu switching, latency when highlighting menu entries or typing, tab switching) when notebooks that are both long and have a lot of math are open. This notebook was the one we noticed with, but it might be just "long and lots of math" that's the problem.
Unfortunately it's tricky to pin down exactly what the problem is - I've tried opening it several times, locally and on the UC Berkeley, cloud-hosted campus hub, and I get inconsistent results. Sometimes my Lab instance gets sluggish while it's open, but other times it seems fairly normal.
Reproduce
To the extent it happens, I suggest
Expected behavior
UI should remain responsive and without high latency on interactive actions (menu open/hover, typing, tab switching, etc).
Context
I see folks in #4292 also discussing rendering issues, though there the conversation went more towards codemirror issues, so I'm not sure if the math aspect is the main problem, or "lots of codemirror instances", or some other combination of factors.
@ellisonbg mentioned we might want to test the KaTeX extension that I see @jasongrout has made recent commits to.
The notebooks the above is part of (all part of a class I'm co-teaching with @pbstark) have a ton of math so it's possible this alternate renderer is not enough for us, but it would be useful to know if it makes a significant difference in rendering speed and/or responsiveness of the UI. If anyone has a chance to test it out, that would be great. I'll report more if I do.
The text was updated successfully, but these errors were encountered: