- When checking whether there is a subscription, there is no need to create feed objects (plus counters etc). Just the number of episodes is enough.
- Downloads section only needs to load the items it actually displays.
- No need to load FeedMedia, just to load FeedItem including the same FeedMedia afterwards.
- No need to convert columns to Strings and back to Longs.
- No need to join favorites when we are only interested in the list of IDs anyway.
AntennaPod is quite slow with huge feeds. The reason is that we have a bunch of workarounds for misbehaving feeds that also make it slower to work with feeds that do not misbehave.
Changes:
- Only start guessing duplicate episodes when no "proper" match is found
- Only parse non-html as HTML for attributes that really need it
- Do not log failed Long parsing when size is not specified
- Try to parse dates with RFC822 first before falling back to workarounds for other formats
I ran a benchmark with "Stuff you should know" (for which the workarounds are not needed) containing 2k episodes. Includes download of 8MB of feed XML (~5 seconds), debug build.
Before: 44 seconds, after: 13 seconds ==> 3.4 times faster feed refresh
This test regularly fails our CI.
The test checked that auto-download kicks in after the currently playing episode
and that it considers the correct item in the queue to enqueue after.
However, because we now use WorkManager, the download can be delayed based
on decisions by the Android system. We cannot assume that downloading already
starts just seconds after playback completes.
I do not know an easy fix for this, and the test is quite complex anyway, testing
multiple different modules at once. So I am removing the test for now.
- Remove video-specific playback speed (no longer needed now that we have per-podcast speed)
- Respect changed speed setting on settings page even if the service is not running
- Do not change global speed when feed setting is updated
ByteHamster
ByteHamster
Fredrik Wallén
Taco
loucasal