-
|
My main question is: at what stage articles list's filters (e.g. show read/unread/important/etc.) get applied during articles' fetching from the DB, and why? As heavily utilizing 'showing only unread articles' filter, I've noticed a lot of cases, where opening feeds with ~10 unread articles takes noticeably longer than ones with ~100. So it looks like the app fetches all, including read ones, articles first, then applies the unread only filter secondly, wasting unnecessary resources and affecting overall UX interactivity/response times, especially while making basic actions like:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
So while I was troubleshooting my problem here, I noticed that after moving my config and database files to a new clean setup I got much smoother experience in response times overall, especially selecting some categories went from ~12 sec to ~1 now. In the end I've found out that for some reason my rssguard.exe was running in a 'Windows 7' compatibility mode: I don't have any recollection of doing such action personally; but I do remember I had severe silent app crashes in the past after updating to a newer version, wonder if this remnant was a result of Windows doing trying to "fix" my problem automatically in the background. |
Beta Was this translation helpful? Give feedback.
So while I was troubleshooting my problem here, I noticed that after moving my config and database files to a new clean setup I got much smoother experience in response times overall, especially selecting some categories went from ~12 sec to ~1 now.
In the end I've found out that for some reason my rssguard.exe was running in a 'Windows 7' compatibility mode: I don't have any recollection of doing such action personally; but I do remember I had severe silent app crashes in the past after updating to a newer version, wonder if this remnant was a result of Windows doing trying to "fix" my problem automatically in the background.