1.8 noticeably slower than 1.7.9

Support requests, bug reports, etc. go here. Dedicated servers / VDS hosting only
jboehm
Bear Rating Trainee
Bear Rating Trainee
Posts: 8
Joined: 07 Apr 2013, 00:53

1.8 noticeably slower than 1.7.9

Postby jboehm » 24 Jun 2013, 09:34

I have a collection of 'deals' feeds (dealnews, techbargains, fatwallet, etc). The folder can easily get several hundred articles overnight. I usually page down repeatedly, scanning the pictures and reading a few words. On 1.7.9, ttrss never broke a sweat. There was no difference in user experience between the first page down and the last. 1.8 starts running into responsiveness problems after only a couple of dozen pages.

Just an observation on Chrome Version 27.0.1453.116 on OSX.

levito
Bear Rating Disaster
Bear Rating Disaster
Posts: 77
Joined: 17 Mar 2013, 04:18

Re: 1.8 noticeably slower than 1.7.9

Postby levito » 25 Jun 2013, 00:37

I think the issue is caused by the floating title. Updating it is quite heavy for the DOM.

Maybe this user style can help:
#floatingTitle { display: none !important }

If not, disable auto-expanding articles and use the hotkeys to navigate.

Or, if you want to get your hands dirty, edit js/viewfeed.js and remove the call of "updateFloatingTitle()" in line 1317 or so.

User avatar
fox
^ me reading your posts ^
Posts: 6318
Joined: 27 Aug 2005, 22:53
Location: Saint-Petersburg, Russia
Contact:

Re: 1.8 noticeably slower than 1.7.9

Postby fox » 25 Jun 2013, 01:36

I wonder if this should help (I think I have somewhat overthought the approach there):

https://github.com/gothfox/Tiny-Tiny-RS ... 64acedb581

roshambo
Bear Rating Trainee
Bear Rating Trainee
Posts: 35
Joined: 19 Jun 2013, 20:03

Re: 1.8 noticeably slower than 1.7.9

Postby roshambo » 25 Jun 2013, 01:43

I've never used 1.7.9 but noticing unresponsiveness too but it's common among all rss readers I've tried. It only happens after viewing usually 100's of articles, depending on content. This worked wonderfully to speed up GR http://tt-rss.org/forum/viewtopic.php?f=8&t=2283. Unfortunately nothing like it for TTRSS yet.

Collapsed, hotkeys and hiding the floating toolbar didn't have any effect. Commenting viewfeed.js did improve performance a bit but doesn't completely fix it for me like purging.

joseph-mx
Bear Rating Disaster
Bear Rating Disaster
Posts: 68
Joined: 19 Oct 2012, 05:19
Location: http://www.mxhub.com/reader/
Contact:

Re: 1.8 noticeably slower than 1.7.9

Postby joseph-mx » 25 Jun 2013, 10:47

i think speed & performance should be on the top 3 priority list for tt-rss .. we know tt-rss is already very well built rss reader in term of features & UI.. we can improve it further.. :|

AngryChris
Bear Rating Master
Bear Rating Master
Posts: 135
Joined: 08 Apr 2013, 02:42

Re: 1.8 noticeably slower than 1.7.9

Postby AngryChris » 25 Jun 2013, 11:35

joseph-mx wrote:i think speed & performance should be on the top 3 priority list for tt-rss .. we know tt-rss is already very well built rss reader in term of features & UI.. we can improve it further.. :|

I agree that any opportunities for performance enhancement that can realized in the core application should be taken advantage of (as fox as done here). That said, I feel I can comfortably assert that most of the blame for any perceived or real performance degradation in tt-rss is likely due to the database and operating system and not the application.

This is not to say that PostgreSQL and MySQL perform poorly, or that Linux is a poor choice of operating system (quite the contrary). Rather the database software as installed by hand or by a major Linux distribution is tuned very very conservatively. Running tt-rss for any appreciable length of time with a moderate number of feeds will quickly require more memory resources than the database software provides out of the box (certainly the case with PostgreSQL).

In addition, most Linux distributions (certainly all the popular ones, even server targeted distributions) have their disk I/O tuned for "fairness" and/or for responsive desktop use (the cfq block I/O scheduler, in my experience, is terrible for databases). After reviewing a lot of Linux and PostgreSQL performance tuning information online and experimenting with various settings, tt-rss absolutely flies on my server.

And when I say "server" I mean "6 year old Dell business desktop PC" (it's a Pentium 4 HT Dell Optiplex GX620 with 4GB of RAM, only 3.5 of which are actually usable. The disks are "super speedy" 5900 RPM jobs). The difference in performance when using tt-rss is night and day. As if a shiny new modern server had been dropped into its place.

So while, as I said, I agree that any opportunities for performance improvement in the application itself should be seized, I think a lot more emphasis needs to be given to basic Linux and database performance tuning skills before blaming tt-rss itself. And in the case of article content slowing down one's browser, well, garbage in, garbage out. No amount of tt-rss platform performance tuning is going to polish a turd like Flash.


Return to “Support”

Who is online

Users browsing this forum: No registered users and 9 guests