-
Notifications
You must be signed in to change notification settings - Fork 221
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
Improve PRs/issues loading performance #1107
Conversation
Great, thanks! Code looks good, I'll give it a run and merge before release tomorrow. |
It's nice to have another person besides @maniac103 helping with development, again :) |
Indeed, exactly that was my thought as well! Unfortunately I lack time due to work and family time, so it's nice to see someone who can help maintaining the app to at least keep it working decently :-) |
Nice to hear that :) Currently I have a list of things I want to address/improve. You can be sure that I won't make ground-breaking changes or add big new features 😅 (I don't even have time to). |
Btw no problem for that, life happens :) |
@Fs00 My email is in the commits ;-) |
Oh, right 😂 |
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:
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.