when I look at the performance metrics from ember inspector it show rendering times which are massively smaller than what happens in reality. Rendering 1000 items take around 6 seconds yet ember inspector reports a rendering time of 300ms! Bearing in mind the api call itself takes <200ms.
I’m experiencing exactly the same. The inspector seems to come with values which are lower than they actually are, but hard to tell this excactly.
The poor rendering performance when rendering just a few hundred (200-500) of models through components within a each is actually blocking our app from a release now. We always had trust that it would work as fast with 200 records as with 2 - silly assumption, I’m still wondering how we never thought about testing with large amount of records before finishing the whole project.
I’m currently tweaking here and there and trying to get things a bit faster - still we have some lists with a few hundred items rendering for 2-3 seconds… that would be unacceptable. I tried to look into the ember ListView but it actually only hides the real problems and does not provide a solution since you can’t search the displayed page properly and have the view in the correct size is a pain! Arguments about just displaying less items, using pagination and lazy loading are sometimes just invalid, I’m sorry I’m not talking about 5 thousend, but 5 hundred models which make any of my browsers crash when rendering with emberJS!
Now we replacing all rendering bottlenecks with good old DOM manipulation by JQuery, I could only cry about this!
Our project was facing the same issues about a month ago, I ended up doing a rewrite of ListView to fit our needs and using EmberCrossFilter to speed up dataset manipulation, we can now display 10k component based rows with live text filtering, sorting and scrolling with sub 35ms filter times and full 60fps scrolling, it does take some work but none of it is inherently an ember problem, we would have had to invest much more time in a solution without Ember.
Those are impressive numbers, congratulations! Can the solution you implemented be made general? I think this is the problem most companies/people would like to see solved in Ember. HTMLBars will (does?) mitigate the problem but rendering and updating a large number of rows will still be a challenge, I think.
When you have time, I’d like to see if you could expand on my example to demonstrate what you’re seeing. I’d love to help where possible and also know about these pitfalls as I make improvements to ListView.
This example uses Ember 1.10, so results may have changes a bit.
As soon as I get a little time in the next couple days I will post a jsbin with a demo that should be enough for someone to get all they need to implement the technique, it is general enough we reuse it in a lot of places but it does have quirks specific to our use, no horizontal scrolling and all items must be same height, both can be addressed easily enough. It also has dependencies that I don’t have time to remove, lodash, EmberCrossFilter, zyngaScroller and polymer gestures.
The performance measurements were all pre HTMLBars, I don’t think just HTMLBars alone would really have helped, especially on mobile. DOM nodes in huge numbers for a complex component repeated over 5k-10k items will just not work no matter what. About 100 items was where we hit the wall on mobile and 400-500 on desktop.
I know it is possible to get great performance out of ember so I made a quick video of an app with with 10k items loaded into a virtual list mostly to encourage people that it is possible, I see this complaint a lot about web apps in general.
Not the best quality video, but it does show 10k components with full 60fps scrolling, sorting, filtering and text search with great performance, between 35ms and 100ms for most filters.
Thanks for that! that gives me hope even if it is probably just a work around. Performance levels in my app so far are okay but we’re not starting from scratch but updating an existing legacy javaee app. Basically I’m at the point where I want to start updating the main results view (which is immensly complex) so performance is really critical here, milliseconds count and the last few versions of ember have really regressed in performance for me. Glad to see I’m not the only one
you could have just used native handlebars? That is my backup strategy as before ember we used this and it was very fast. Its proof that ember can get to these levels of performance given enough time.
@douglasbhill sweet! Impressive! If you have any chance to share your ListView with everyone, it would be a great benefit to a lot of people!
@jasonmit I haven’t done anything to our latest RC of our app yet. It’s currently on hold and I’m trying to find a solution for the bottlenecks, but the “JQuery appending elements to dom”-solution is one of the fastest so far. But, since I notice I’m not alone, I will set up a jsbin with what we do to demonstrate the issue, your jsbin is pretty acceptable… But make each element a component and fill it with some logic, some conditional classes, a few links, computed properties, that’s when our each list became really slow! Unbounding the properties helped a little, but was still a drip on the hot stone…
@adriaaaaan sounds interesting, but what do you mean by native handlebars?
Great to see I’m not the only one struggling with this, gives me hope there might actually be nice ember-way to solve this issue and finally get the app released.
@Preexo I mean just using http://handlebarsjs.com/ you will be able to mostly reuse your template. the only downside is handling actions is a little more complicated. If you override the render method in your view class you can do the drawing yourself. we originally used this for our datatables but then removed it as a classic case of premature optimisation (most other tables can get away with only 50 rows per page).
@douglasbhill I would also be interested in seeing your solution. I built my own a few months back that achieved reasonable performance at ~100k items. I’m really hoping that the ember community can settle on one extensible addon and I think Ember ListView could be that solution. I also know that @fivetanley was looking for sponsors to complete more work on that project.
Most disappointingly it seems that HTMLBars wont solve our performance issues. I realise its early days but so far I’m seeing worse performance not the massive improvement it was originally showing. A similar scenario as described above renders in around 8-10 seconds as opposed to the 6 in the example above.
@adriaaaaan I get the same feeling about poor performance when rendering large lists in HTMLBars too, but maybe we will be surprised and everything will be much faster soon… I still hope
@southpolesteve I agree, an community solution to the list-render-problem would be the best, maybe ListView is the right start for that
I haven’t had time to setup a jsbin to demonstrate our use case and the poor performance because I had to get the RC of our app done before end of this week - I did it by rendering the items in the each lazy, one at a time and only if I scroll and it comes into the viewport… that works - I don’t like it, but it works and it is really really fast!
