Slow Rendering of 150 item table

Performance
1

I am on ember 1.9.1 and trying to render 160ish items and its taking about 3 seconds. I’ve removed the bindings for most columns using the unbound option. My template looks like the following:

<table>
  {{#each item in model}}
    <tr>
      <td>{{item.isFlagged}}</td>
      <td>{{item.status}}</td>
      <td>{{unbound item.title}}</td>
      <td>{{unbound item.list}}</td>
      <td>{{unbound item.scope}}</td>
      <td>{{unbound item.org}}</td>
      <td>{{unbound item.approver}}</td>
      <td>{{item.time}}</td>
      <td>{{unbound item.submitted}}</td>
    </tr>
  {{/each}}
</table>

Each item is a DS.Model with a fair amount of relationships, but even when all data is resolved and I switch between views of data already loaded it continues to take about 3 seconds in Chrome.

I’ve tried using the Chrome ‘Timeline’ tool, but I don’t know what I am doing. It shows my click (to switch views) then there is a large number of ‘Parse HTML’ rows and 11 GC events impacting ~8 MB each GC. So I am surely doing something wrong but I don’t know what.

What are the next steps for troubleshooting and tracking down my issue?

Cross posted from: ember.js - Ember table render performance - Stack Overflow

2

this does sound a bit on the high side, but binding can be super expensive.

try to isolate the impact of the various bound properties and unbound ones, basically delete td to find what each one is costing you.

If I had to go with my gut there are 3 options here

  1. That a CP is very expensive to calculate and costing you tons of time
  2. Something about item.time
  3. Just too many items being displayed
3

I’ve played around with it and just tried outputting the status of each item which is just a string and it still won’t really be acceptable performance. So at this point are my options list-view or just showing a fewer number of items?

4

yeah that or cloaked view GitHub - eviltrout/ember-cloaking: Support for not rendering offscreen views in an Ember app for performance if you need random heights

(or render it to a string and wack the whole string on to the page thus unbinding the #each)

5

150ish items seems fairly small to be running into these performance issues to me (I have seen good info about 1.10 gains presumably from HTMLbars) but I will take a look at ember-cloaking and list-view. Thank you so much for your help sam.

6

Cloaking will definitely help, but as far as Ember’s limitations go 160 is a lot for a list, and 1.8 and 1.9 took a performance hit with the metal views prep getting ready for 1.10. This sort of awful render performance is precisely why HTMLBars is hugely anticipated. Ping me if you need help with cloaking.