gpodder / gpodder

The gPodder podcast client.

Home Page:http://gpodder.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Is there a way or preference to increase the use of Processor? in order to reduce episodes load times.

Snippet24816 opened this issue · comments

My computer is using maximum of 25% would it be possible that it used more cpu like 50% in order to load faster the episodes and reduce startup times?

Regards

Do you have a 4 core processor? Gpodder only uses multiple threads when downloading, so during startup only one thread would be active, and a 4 core processor would show a maximum of 25% usage. There are two bottlenecks during startup: loading from disk and loading episodes into gtk's treeview. Getting a fast SSD or reducing your database size by storing fewer episodes is the only way to make it load faster. And since gtk is single threaded, reducing the number of episodes is the only way for gpodder to fill the treeview faster.

I profiled the episode treeview code a while back and 62% of the time was spent inside gtk when you only have deleted or downloaded episodes. The other paths are really slow, so I suggest not keeping around a lot of episodes that aren't either deleted or downloaded. Moving the 38% of non-gtk code to a second wouldn't make it that much faster because it must send the data back to the first thread to send it to gtk. The non-gtk code is also on a timer, so the main thread is idle briefly every 500ms to keep the UI responsive. That would be much harder to guarantee if one or more other threads were constantly sending data to the main thread. Two threads would completely saturate the main thread, except in the non-deleted/downloaded paths where you could see three threads feeding the gtk thread and using 100% cpu on a 4 core processor. If someone wanted to try implementing a responsive worker pool, you might only see 25% faster loads. But it would need to detect single core systems and not use a second thread because that would kill performance on those already slow systems.

Another way to improve startup speed is to disable the "All episodes" in podcast list in View menu. You lose that feature, but gpodder wouldn't need to load every episode, only those in the first channel.

There are two bottlenecks during startup: loading from disk and loading episodes into gtk's treeview.

This could be fixed by porting to Gtk4 and using its GtkListView and GtkColumnView widgets. If my reading of their API is correct, these allow models with dynamic updates, so the "loading episodes into gtk" step is removed (or moved into the phase where the individual list widgets are about to be shown).

This of course is easier said than done.

Do you have a 4 core processor?

2 Cores and 4 Threads

Thanks for explaining, good to know this.
Question: for the second bottleneck instead of reloading the whole channel could only the new episodes be added without having to load again all the older ones? Most likely is not easy stuff

reloading the whole channel could only the new episodes be added without having to load again all the older ones

Nope, every episode in the channel is loaded into the episode list, even if you can't see them. They are then filtered based on the mode you set in the View menu, or when you perform a search. It would be possible to filter them early and only load the filtered episodes into the list, This would probably have the same load times, but switching View modes would be slower, and searches would be terrible, causing a refilter for every key typed.

I see, thanks for explaining 👍