Very slow transition possibly caused by removing table from DOM - ember.js

Question

I'm using Ember JS 2.3.0, Ember Data 2.3.3 and jQuery 2.1.4 and I'm having an issue when trying to transition away from a page with a HTML table component on it. The table component is populated with data from this Ember Data call:
this.store.query('log', {filter: {
created_at_from: moment().subtract(1, 'month').format('DD/MM/YYYY'),
created_at_to: moment().format('DD/MM/YYYY'),
object: 'IsoApplication'
}})
which having looked in the developer tools "Timeline" and "Network" tabs is resolving in good time. It has no special jQuery events etc attached to it and is simply a plain HTML table made dynamic with Ember.
However, when clicking a "link-to" helper that transitions away from the page with the component on it there is a huge 10 second delay before the destination page renders. During this time nothing seems to happen and having used the developer tools "Timeline" and drilled down it seems that the delay occurs when the "removeFromListeners" function is being called (see attached timeline screenshot). No asynchronous stuff is happening at this point and therefore no loader appears but it seems that tearing down the table is the problem because if I remove the table component from the template the issue disappears. Without the table component the page transitions almost instantly.
I have attached the timeline screenshot to see if anyone can help to pinpoint the possible cause of this problem.
Any suggestions would be welcome.
Thanks.

Answer 1

Ok, after significantly reducing the number of rows in my table I discovered that the issue went away. #runspired provided a detailed and very helpful description of why my issue occurred, which I have posted below to inform others who may have similar issues:
there's a number of things going on here
I've given a few talks on this (including two podcasts on Ember Weekend (episodes 38 and 39))
I wish I had my chicago-ember talk on it recorded but I don't
but basically, comes down to three things as to why this is slow
and none of it is actually because "dom is slow", that argument masks the truth of the matter
1.) don't render the universe, render the scene
easiest analogy is take any video game you can think of, especially one in which you can "pivot" the camera view quickly
that pivot is a lot like scroll
you really only want to render what's visible at the moment, and prepare content that's closer to the camera's view
but it makes no sense to prepare content that's far out of view
this is a lesson that every native SDK and game SDK has baked in, but which no JS framework has yet realized
when people say DOM is slow, it's really because they are trying to render far more things than they ought to
2.) is a bug in most browsers
memory allocated for DOM is always retained by the tab that allocated it
this allocation persists beyond the lifecycle of your page
it's a true leak that hopefully Chrome etc. will fix soon
or basically, the allocation heap size made for DOM can only ever grow
you can reuse allocated memory, but you can't shrink it
this means that if you generate a huge amount of DOM nodes, even once you tear them down there's a high memory overhead for that tab
which causes performance issues in other areas because less memory is available for JS allocations etc.
this problem is bigger on mobile, especially android, than on desktop. But it can affect desktop too.
Something going hand in hand with 1 and 2
is there's a definite limit to how many DOM nodes you can render before the browser starts chugging
I've found that limit to be roughly 40k DOM nodes, varies from as low as 20k on older android devices to > 100k on Safari
but 40k seems to be a limit which if held to as a target works well for all platforms
if you have 700-2000 table rows, and each row has maybe 3 TDs, and each TD has just one link or span or other element, and then in that you have some text
6,300 - 18,000 nodes
or basically, you're dealing with half of your max budget with that setup
just as the content of the rows
so 7002 - 20,002 nodes counting the rows
and it's likely that 9 nodes per row is a very low estimate
if we double that
you're exceeding that max
and 18 nodes sounds more likely
3.) GC events stop the world
[9:28]
even though the memory allocated by the tab is retained
the allocation IS cleaned up
(so it can be reused for more DOM later)(edited)
so you're releasing the memory for at LEAST your max DOM size (likely larger) all at once
that's a lot for the browser to clean up on
it's also likely a lot of arrays and array observers are being torn down in this time.
#runspired is also the author of
https://github.com/runspired/smoke-and-mirrors which is a project that:
focuses on improving initial and re-render performance in high-stress situations by providing components and primitives for performant lists and svelte renders to match a core belief: Don't render the universe, render the scene.