Thanks for the bug report.

I do realize that there are quite a few possible improvements to the app, especially in setups with a lot of podcasts/episodes. I'm actually currently trying to do a refactor of the base code that handles this. So, I do hope to make some improvements in the future.

Having said that, you mention a few puzzling observations and remarks:
- First of all, are you running this on old, slow hardware or on a recent, fast machine? Just asking to know what kind of performance to expect. (I've been running Kasts on a raspberry pi for a few years myself.)
- You mentioned that the app was slow at startup with only one podcast.  This sounds a bit puzzling.  Is this a podcast with hundreds or thousands of episodes. Because I don't really recognize this, except maybe in one situation: see remark below(*).
- Regarding images: only the images that are visible on the screen are in memory at any given time, so images should not be a bottleneck at all. The images are downloaded the very first time they are accessed (and are then cached).  Both the downloading and retrieval from cache is done asynchronously, which can give the impression that these are slowing down the app, while in fact this is actually done to speed up the rest of the app.
- Similarly for most of the list pages: only elements that are actually visible on the screen should be loaded into memory.  I've got about 30 podcasts, with 6000 to 7000 episodes, and all the list pages load nearly instantly for me.
- The one exception right now, I think, is the Play Queue. If the queue was the last active page, then I think it will load all episodes into memory on startup.  That's the main part I'm trying to refactor right now. However, I've only seen observable slowdowns at startup when the episode count on the queue is going into the hundreds of episodes. Is this the case for you?

So, looking at the symptoms that you are describing, I have a hunch that the slowdown that you observe is actually due to a large amount of episodes in the queue, and not the total amount of podcasts and episodes per se.  Is this correct?
If you are ok to experiment, could you perhaps try to cut the amount of episodes on the queue down to 10 or so? My expectation is that this will remove all of the slowness symptoms. But if it's not the case, I'm also very eager to hear, since then it's probably a new type of bug/slowness.

If my analysis is correct, then all I can offer right now is that I'm working on improving the large queue slowness.

PS: Unfortunately, removing episodes from a queue with a lot of episodes will also be extremely slow, as the amount of operations currently goes quadratically with the amount of queue items. So please expect to wait up to one or two minutes for the operation to finish.

NB: I really never imagined anyone having more than a few tens of podcasts in the queue at any given time, since I envisioned it as a list of things you want to listen to in the near future. That's part of the reason why I didn't fully optimize everything from the start. But apparently that's only my opinion; I've seen quite a few bug reports where people are using it like an archive. :)

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! :-)

Thanks for the quick reply and the detailed report of your observations and perceptions.  It seems like your observations do line up with what I would expect on older, slow hardware. So that's good.

All of the things that you mentioned are slow, are things that I recognize as current bottlenecks. Also the memory usage lines up with my expectation: there are a few things that are kept in memory that are not really needed. I'm trying to tackly these right now, so hopefully this will improve in future versions. I can't promise it will be in the next major release, though.

Oh yeah, one more thing: I'm not sure that the memory usage reported by top/htop fully represents reality. I know that the linux kernel tries to be very clever with caching things if there is plenty of memory available (which apparently is the case for you). In other words, it tries very hard to speed things up by caching and pre-caching things into memory, even though the app itself does no caching of its own. I'm not an expert in this matter, but I know that you should take that reported memory usage with a grain of salt. But that reminds me that I should try running something like valgrind again. It's been a while since I've done that.