mboinet / ttrss-mobile

A mobile webapp for Tiny Tiny RSS

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Poor performance with 305 feeds / 1375 unread items

cgrinds opened this issue · comments

OS X 10.8.2 Chrome 26.0.1410.43
Here's my testcase.

  • Login (this is fine)
  • Click "Uncategorized" category (this is fine)
  • Click the first feed in the list (this is fine)
  • Click the back button
    When I click the back button, my late 2012 laptop shows Chrome running at 100% CPU utilization for 21s !!
    During that time the app is unusable.

Using Chrome Dev Tools I profiled this and here's what I see.
Backbone's done callback eventually calls FeedsPageView.render which iterates
through each feed calling FeedRowView.render. Near the bottom of the
FeedRowView.render method you call $lv.listview("refresh");
This method takes ~ 70ms on my machine.
And since that's 70ms per feed * 305 feeds it's ~21s to refresh alone.

  var $lv = window.feedsPageView.$("div:jqmData(role='content') " +
    "ul:jqmData(role='listview')");
  $lv.listview("refresh");

I dont think this code is needed, and if it is needed it would be better to call it once in FeedsPageView.renderList(). Either way, I removed it and everything still refreshes/updates fine, just much faster.

The other thing I noticed is FeedsPageView.renderList() is actually called twice every time you press the Back button which hurts performance too.
This happens due to the feeds route method (line 1348 https://github.com/mboinet/ttrss-mobile/blob/master/main.js#L1348)
The FeedsPageView's render method is called directly and then the next line of code feedsModel.fetch() ends up calling render() too. This happens via Backbone's sync method calling the collection.reset method.

Rendering the view twice hurts performance. I don't know backbone but I changed

this.goto(window.feedsPageView.render().$el);

to

this.goto(window.feedsPageView.$el);

to eliminate the double render.

With these two changes ttrss-mobile is much faster for me.

Thank you for the report. I'll try to fix this soon.

For the first problem, you're right, the row should not trigger a list refresh. Fixed in 0a33d5f.

For the second problem, I need to find a better solution.

I can't find a way to get an intelligent update: only add missing rows or updating rows that changed. jQueryMobile make the row view lose its el reference. I can't easily find back the li element after list has been enhanced.
I could probably do something with the id of the feed returned by TTRSS API and store it as the id of the li element.

With your solution, I think there would be an empty page and no loading... message on first access. On a fast connection it's OK, but on a cell network it's annoying not to know that the app is working in the background.

I'm listening if you have other insightful comments (this was a wonderful report you did) :-)
I also let this issue opened as it's indeed a bug, the app should not render two times if nothing has changed.

For the categories, I changed a lot the way it works. Now, drawing and updates should be kept to a minimum for this page (categories).
I'll try to do the same for the other pages...

It's also working for the Feeds page now.

It's ready in master as of c1af994

Awesome. Thanks for all the work on this