-
Notifications
You must be signed in to change notification settings - Fork 5
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
improve rendering performance #18
Comments
Can we measure/estimate the impact of these suggested features on performance? Eg. how many DOM elements (% of total) they create? Or more generally, could we try to identify where the main bottlenecks are? (The suggestions are understandable but switching them off would impact usability, so it's not a too clear-cut situation.) I would certainly prefer to approach the solution not by commenting out, but to either disable conditionally or by setting an option in the app. |
There is some profiler available in Chrome DevTools which can measure at least number of DOM nodes and memory usage. Need to explore all of its features. Generally, the more nodes/edges in graph, the worse gets performance. Any improvement in the area of rendering a single node/edge should have big impact. I need to further elaborate this issue but overall, I agree that disabling the features (in any way) is preferable solution over commenting them out. |
Issue #18 fixed graph loading issues that caused the app to crash
When more than a few nodes are loaded, app gets slow and not very interactive. The issue is that there is a lot of DOM elements that need to be rerendered often resulting in poor performance.
Consider removing/disabling of some of the nice-to-have-but-expendable features such as:
The features should be either commented out or conditionally disabled (e.g. if node count > 100).
The text was updated successfully, but these errors were encountered: