Improve PRs/issues loading performance #1107
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While I was investigating why loading a PRs with lots of comments was extremely slow, I opened up the Android Studio network profiler and saw this:
![pr_before](https://user-images.githubusercontent.com/30041551/132731352-1405224d-1a45-4853-b010-55ba1e57fea9.png)
What was happening in thread RxNewThreadScheduler-23 was that these API calls used to load the PR conversation:
gh4a/app/src/main/java/com/gh4a/fragment/PullRequestFragment.java
Lines 315 to 320 in dfdf3e1
were all being executed sequentially!
To execute them in parallel, I only needed to explicitly subscribe each of those
Single
s on a background thread (63d4032).After this change, this is what I saw in the profiler:
Much better. The conversation of that specific PR (PowerShell/PowerShell#9900) now takes half the time to load (from 20 to 10 secs).
I noticed that also issues had the same performance problem (albeit much less serious), so I fixed it also for them (ff17c68).
There are some other misc small changes in this PR:
Schedulers.io()
rather than onnewThread()
(0aef6f6). This avoids spawning a thread for literally every asynchronous action in the app, which is unnecessarily costly.io()
uses a shared thread pool that grows as needed, so we get the benefits ofnewThread
but reusing previously allocated threads whenever possible.