https://bugs.kde.org/show_bug.cgi?id=515396
--- Comment #1 from [email protected] --- 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. :) -- You are receiving this mail because: You are watching all bug changes.
