Significant performance degradation when loading large number of components


#1

Hey all!

We are looking into building out a component similar to Ember-Light-Table and hit a bit of a snag. This component utilizes component contextualization to improve on flexibility and implementation.

An example setup:

{{#my-table model=dataModel as |table|}}
    {{table.column name="Column 1" property="dataAttribute"}}
    {{table.column name="Column 2" property="dataAttribute"}} 
    {{#table.column name="Column 3" property="dataAttribute" as |column|}} 
        {{some-helper column.data}}
    {{/table.column}}
{{/my-table}}

To put in place a cleaner, more “modern web” UI, we are looking to set up a table without pagination. Or, if need be, setting the threshold high enough that most users never see it.

The catch: this needs to be ADA compliant, removing solutions like Vertical Collections - unfortunately, Infinite scrolling just does not work very well with screen readers.

With a reasonable number of records, there is no issue… but you start encountering long running script errors in IE at around 250 records.

Using Ember Concurrency, we’ve managed to suppress these errors… though the records still take a significant amount of time to load, lagging the UI a bit in the process.

Gathering some metrics, I’ve found that Ember components take around 1ms to render. This means that a table of six columns and 400 rows takes - as a baseline - 2.4 seconds without any overhead. With computed properties and such, I’m seeing about double that number.

Has anyone run into an issue like this one? (rendering a large number of elements takes a massive amount of time)

If so, how did you solve for it? Do you know of a way to streamline the render? From what I am seeing, it looks as if a significant amount of time is spent drawing to the screen. This being the case, a potential fix would entail some kind of “buffer”. That is, instead of many small changes to the DOM, buffer the changes and write them all at once. (or in chunks)

Let me know what you think.

Thanks for the help!


#2

What Ember version are you on?


#3

We are on 2.14.1, though I’ve tested with 3.1.1 and actually noticed even worse metrics.


#4

Are you testing a production build (--environment=production)? Just checking because the performance characteristics are very different if you just run ember s.


#5

There is definitely a difference, individual component rendering goes from 1.3ms/component in a Prod build to 1.7ms/component in a Dev build.

Fairly substantial difference (almost 30% improvement), but this still means that a 400 record table with 6 columns takes over 3 seconds to render in IE (at best).


#6

If your use case is really slower in a 3.1.1 production build than a 2.14.1 production build, that is interesting and if you can share a working reproduction it would be worth filing an issue about it.

But in terms of solving your immediate problem, there are several possible paths.

Best option: make vertical-collection accessible

I think the very best option would be to come up with a strategy for making vertical-collection itself accessible. This would benefit a huge number of users while also solving your problem.

My hunch is that we could provide more traditional pagination controls that only screenreaders see. Sighted users would get the current behavior of vertical-collection. Screen-reader users would hear the first page of results, and also hear links for next page, jump to page N/M, etc. Those links could programmatically jump the vertical-collection to the right places. After it rerenders with new rows in DOM, you might need to give a hint to screenreaders to re-read the changed content (this is already an issue for plain old {{outlet}} too, so you can reuse whatever strategy you’re using there. ember-a11y uses focus manipulation).

I would suspect that these added pagination links would have accessibility benefits for keyboard users too, not just screenreader users, since you could tab over to the links and activate them all by keyboard. That may be an argument for showing them to everyone, at least as an option for people installing vertical-collection. But a more elegant solution to that part of the problem is probably to give the vertical-collection its own native keyboard controls so that the table can be focused and scrolled with up and down keys.

It would not surprise me if this strategy is actually better than dumping all the rows into the DOM, because that strategy doesn’t give screen reader or keyboard users an especially good way to navigate thousands of rows. I am not an accessibility expert, all of this deserves real user testing.

Second best: optimize your giant table

But assuming you really need to keep all the rows in DOM, that does cut out the most accessible prepackaged optimization strategies, which are all about limiting the work to things that are on screen. You’re setting yourself a hard task, which is rendering vastly more stuff than could even all appear on screen at once (or even be read productively by a screen reader – because really, who’s going to listen patiently through thousands of cells?).

The most impactful thing is probably to have less components.

Your code snippet doesn’t make it clear how many you already have, because we can’t see how table.column is implemented. If it has a component per cell, yeah, that is probably pretty expensive. You will get a boost by not doing that.

Often you can do this kind of refactor without losing any features. If the cell component has computed properties, move that work into helpers. If it has actions, move the actions up to a parent component, pass the actions down, and parameterize the arguments to the action so that you can still operate on the correct cell data.

You can still give each cell customized content by yielding, just as you do in your example. Though keep in mind that you’ll keep your component count lower if you inline some DOM like

{{#table.column name="Column 3" property="dataAttribute" as |column|}} 
    <div class="some-special" {{action "mogrifyTheData" column}}>column.data</div>
{{/table.column}}

rather than invoke a component per cell:

{{#table.column name="Column 3" property="dataAttribute" as |column|}} 
    {{some-component column.data}}
{{/table.column}}

There is a tradeoff here between developer convenience and runtime speed. It’s a tradefoff we are constantly working to bend, and is has gotten steadily better. But if you want to cheat the tradeoff, Miguel Camba has a library that helps you do compile-time components so that you can author with components but not pay their cost at runtime. And here’s a video about how it works and how to use it. This is using nonstable APIs, so if it breaks you get to keep both pieces. How practical it is for you depends on your willingness to step in and learn how it works and fix it if it needs updating.

Sticking to safer public APIs, another option is to write a helper that builds up some DOM Elements and returns them. You can do whatever you want to construct optimized DOM in the helper. This can be cheaper alternative to a component for reusable bits that don’t need a lot of fancy behavior. Just be aware that if any of the inputs to the helper change, it’s going to rerun completely, and rebuild all of the DOM that it built, so anything stateful in there like <input> could get blown away.

Another option that is all public API, though new, is to enable the template-only-glimmer-components feature, and refactor your most common components to be template-only glimmer components. You’d do that by:

  1. Use Ember 3.1
  2. Add the @ember/optional-features package to your project.
  3. Run ember feature:enable template-only-glimmer-components.
  4. Refactor your most used components (like per-cell ones) to have no Javascript files, only templates files.
  5. Adjust their templates to the new glimmer component semantics, which means:
    • they will no longer get an automatic wrapping div – you get to put the outermost div directly in the template.
    • they should refer to their arguments like {{@whatever}} instead of {{whatever}}.

I haven’t measured the impact of this, but it allows Glimmer to skip a bunch of work, so it seems like it could measurably help your situation. To avoid needing a javascript file, you would do many of the same things I suggested earlier, like refactoring actions into parent components and refactoring computed properties into helpers.


#7

Unfortunately, I am unable to share my code… however, you know one of my colleagues, they’ll ping you shortly with some ideas.

Make vertical-collection accessible

This would definitely help, but there is an inherent issue with infinite scrolling solutions not playing well with screen readers. We have been talking a little bit with a couple of the Smoke and Mirrors devs, and will likely be jumping on a call to discuss issues (including this one), as well as planning on solutions moving forward once runspired is back.

Pagination would be a great idea, as that is the normal solution in making large data sets accessible, we will just need to make sure there is an easy way for screen reader users to filter through a large data set - I will play around with this idea to see how well it works… as it very well might solve many of my issues.

Generally, dumping a ton of data into a page breaks accessibility convention beyond just the simple “screen readers have issues with the data”. While doing so does not technically break any rules within WCAG… in my opinion, it definitely breaks the spirit of the third principle (content being understandable). So introducing some controls to allow a user the ability to not infinitely scroll through some content would definitely be a boon for users that are not only visually impaired, but users with some form of cognitive impairment.

Optimize my giant table

This is likely something that will need to happen even with the introduction of pagination controls within Vertical Collections, as I’ve noticed a small bit of lag within the VC addon in IE on scroll. Stripping out pretty much everything, defining tagName as blank and defining it within the template, and handling events higher up in the chain, I’ve reduced the per-component render time down to around 0.76ms. Still pretty high, as 250 row/6 column table takes a couple seconds to render… but definitely getting closer to a reasonable render time.

Glimmer Components

Definitely something I’ve also been looking into. I was having issues getting them into the Ember App, however, so I will most certainly give this a try.

Thanks for the advice! It is most certainly appreciated!

Best,

Jason