Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use multiple threads for refreshing feeds #7126

Merged
merged 6 commits into from Apr 27, 2024

Conversation

0x082c8bf1
Copy link
Contributor

@0x082c8bf1 0x082c8bf1 commented Apr 20, 2024

Description

The feed refreshing uses only a single thread which can take quite some time when many feeds are being refreshed. Do this on a few threads to speed this up.

From my testing this can reduce the time it takes to refresh the feeds from 30 seconds to 11 seconds (Ran with 15 outdated feeds).

Checklist

@ByteHamster
Copy link
Member

Thanks for working on this. It looks like this breaks the progress notification, which now always displays the entire list of subscriptions instead of showing the ones that still need to be refreshed. Could you have a look at that, please?

Update the notification when done downloading instead of before since multiple will be running at the end and the notification would show feeds that are already done.
@0x082c8bf1
Copy link
Contributor Author

Of course, just pushed a change to fix that.

refreshFeed(feed, force);
//Unchecked is used to prevent a race condition where a feed finishes downloading before
// we're done submitting all of the jobs
List<Feed> unchecked = new ArrayList<Feed>(toUpdate);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this copy actually needed? You are only updating the list in a synchronized block anyway. Is this maybe a leftover from an earlier experiment?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it might be, because we are iterating over toUpdate and I guess we shouldn't remove items from a list we are currently iterating over.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, right

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, that's correct if it were to somehow manage to get to the remove before the for loop was done, we
d get an ConcurrentModificationException so the copy is there to prevent that.

// we're done submitting all of the jobs
List<Feed> unchecked = new ArrayList<Feed>(toUpdate);
updateNotification(unchecked);
ExecutorService executor = Executors.newFixedThreadPool(5);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

5 sounds a bit arbitrary. I think the default was 4 when we had parallel refresh before (which got removed after a rewrite of the download code)

@ByteHamster ByteHamster merged commit f698225 into AntennaPod:develop Apr 27, 2024
6 checks passed
@ByteHamster
Copy link
Member

Thanks! Will be released in 3.5.x

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants