https://bugs.kde.org/show_bug.cgi?id=515396
--- Comment #2 from KDE User <[email protected]> --- Hello again, thanks for the thoughtful response. My hardware is pretty old, it's Haswell era Intel hardware with no dedicated GPU, it still performs very well for the tasks I do with it (thanks to all open-source software and developers!). I would put my machine on the slower tier for that reason, but it has sufficient RAM of about 12 GB. So basically for app startup, I didn't really care about startup speed at the very beginning when I found out about Kasts. I quit Spotify and subscribed to some of my podcasts from Spotify with Kasts and synced them with Gpodder, I still have to subscribe to a couple hundreds of them from Spotify later. I think after adding about 50 podcasts, initial startup slowed down a bit, but now after reading your response I think me changing the settings might've also contributed to the slow performance. The first time I started using Kasts, I saw all podcasts were marked as played when adding podcasts by default, so I decided to change default podcast adding behavior from "mark as played" to "mark as unplayed". That added number tags in the subscriptions page with thousands of episodes. Today, I decided to revert it back to "mark as played" by default and converted all episodes from unplayed to played. This seems to have improved the perceived performance a bit, maybe. My queue didn't have many podcasts, I think it had about 20. So I decided to remove them all and test, it seems like the application may have become a little faster now. However, initial startup of Kasts is still a little bit slow, but that's okay. I tested page loads of individual podcasts, and you're right, they are instantaneous for me too. I noticed that going to different pages now fluctuates the memory usage by a lot. Like, going to the episodes page makes the memory go up to 1.1 GB. But resting at queue page gets it to around 500-800 MB. Right now the lowest I got the memory to be is 480 MB, it's when I am in the queue page since it has only one podcast in the queue. I usually disable animations for all apps, and I kind of see some lag when switching between pages compared to more lightweight apps like KClock or Elisa. I think all the small stuff I noticed and resource usage in htop made me feel like the app is slower than it is, hence the bug report. I'm kind of nitpicky, apologies for that. I'm glad to know you're working on improving Kasts! I think this bug report can be closed if you want, since it's pretty vague and not talking about a specific issue, but about an overall issue that improve's with time and effort. Right now Kasts is pretty decent in performance for use when I want to listen to podcasts, thanks for making it! :-) -- You are receiving this mail because: You are watching all bug changes.
