Fasthub: Issues/PRs are opened much slower than by OctoDroid

[zvirja]

If you navigate to the My Issues list and try to open any issue, it's being opened for a couple of seconds (about 3-4 secs with WiFi). If I do the same in the OctoDroid, issues are opened about twice faster.

I'm not sure about reasons, but visually it looks like FH is performing two requests one by one. After the first request you get header, while after the second one you get the issue body. On my device both them take almost the same amount of time - about 1-2 seconds.

I'm not sure why, but OctoDroid is able to open them much faster. It also seems to perform two requests, however they took about 0.5 second each. It could happen that it performs them in parallel, but I'm not sure.

This issue is reproducible both on WiFi and on 3G. Sometimes speed is better, however it's never the same as in OctoDroid.

This issue is not specific to issues only and I noticed the same behavior with PRs. Also it seems to happen with any screen which is present in app - in general application is felt slower than OctoDroid.

I like this app and believe that in order to compete with alternatives, it should have the same responsiveness - no compromises :)

If you need some diag info to investigate, let me know.

---

• FastHub Version: 2.1.0
• Android Version: M
• Phone Model: Xiaomi MI5

[k0shk0sh]

I never meant to compete with others nor to behave like others, I understand that it might be slower but you have to know the facts/reasons behind that, for example:

Issue:
1- Load Issue with Reactions.
2- Check if user is collaborator.

• Load Issue Timeline in parallel with below
• Load Issue Comments
  3- Construct the labels to be merged as what GitHub does for labels & assignees.
  4- display them.

now for PR is more complicated:
PullRequest
1- Load PullRequest from API
2- Call Issue API with PR number to be able to get the Reactions & merged it to the PR (blame GitHub API)
3- Check if user is collaborator.
- call API (PR comments, PR timeline, PR Status, PR Reviews, PR Review Comments) and after all that merge them all together.
- call commit lists.
- call commit files.

Looking at above, I guess you would guess how complicated stuff are, in the other hand, OctoDroid does not have most of what I mentioned above.

[zvirja]

Thanks for the wide explanation 👍

I didn't encourage you to compete with other. Rather, I noticed that this app is significantly slower than OctoDroid. I felt that this is very important argument when you decide which app to use for everyday usage. Unless you clearly understand _why_ you should wait, you will definitely pick up the quicker app. As result I decided to report this issue.

I believe I've got the idea - it takes longer because you offer more features. As result, you need to make more requests and computations which takes more time.

I don't know all the pipeline and the internal architecture, however is that possible to somehow decrease the initial rendering time? We could render first the basic information and later incrementally update screen with additional information. For instance, you mentioned that you load reactions. This is definitely non-critical information and I might not want to wait for extra second to see them. Rather, I would like to work with comments as soon as possible, while reactions might be fetched and added later. This way you will still display all the features you need, but initial load time will be much smaller.

Would it be possible to improve situation this way? Likely, it would complicate things, however I believe that it worth it - 4 secs for the issue is definitely too much :(

[k0shk0sh]

I don't think that this is possible, the reactions has nothing to do with calling different API, its just a matter of sending a header to github to tell it pass me the reaction object along side this & that.

Its definitely with the idea of merging everything on one screen which previously I wasn't doing, but people wanted it to look something like how GitHub does render these, saying that, I couldn't render items first due to the fact that after all the merging i'm doing with each separate API, i'll have to sort them manually in this case so yep, its complicated & I hate that you wait but its something outta of my control if GitHub has a better API architecture I would really make it more faster at least.

[k0shk0sh]

@zvirja fyi: I'm working on revamp of the whole Issue/PR timeline & guess what, the API calls reduced from 5 or more APIs to only one in issues & 2 in PR. it will be in the next version :)

[zvirja]

@k0shk0sh Sounds great, will be looking forward to the new update! :+1: