UI thread becomes unresponsive while loading commits

[BitBlitObviMormon]

Description: The app suffers from a performance issue where the page becomes unresponsive while loading more commits which seems to be exacerbated by poor internet and/or git repositories that have lots of branches.

Possible fix: Lengthy or blocking javascript code should be run on a web worker to prevent from blocking the UI. As I've looked through the code I noticed that async functions are used frequently, however these will still block the UI thread. Web workers are fairly limited in what they can do (for instance they can't modify the DOM) so the fix can be anywhere from simply rewriting a few async functions to use web workers to requiring a code rewrite with workers in mind. I'll need to look at the code some more to give a more definitive answer.

Version information:

• Windows 10
• Chrome 109.0.5414.120 (64 bit)
• Le Git Graph 1.1.2

[NirmalScaria]

Seems like this is the most serious issue presently. 3-4 clicks on load more and the extension practically becomes unusable. I have tried having a look at the code to see for possibile fixes, and I will look into it further. It would be really helpful if you could share details about why this happens if you come across some insights. @BitBlitObviMormon

[BitBlitObviMormon]

You would probably know better than I why the code takes a while to calculate in the first place, however, one important thing to know about Javascript is that all of its code runs in a single thread (usually the UI thread) - even async functions are single-threaded at their core. In order to keep the UI thread free, code that does a lot of calculations will need to be run in a separate script on an HTML Web Worker. All code that is run on that script will be single-threaded as well, but will run on a different thread than the UI (and the other scripts you have running).

If the code is expected to take a while then the simplest fix would be to have the UI handled by one set of scripts while the script that's computationally expensive is run separately on a Web Worker. Because the Web Worker is largely unable to access the DOM it will have to communicate with your UI script in order to update the UI. I haven't yet learned how to use Web Workers properly (because true multithreading is pretty dang tedious) so I'm not sure what else to say.

An easier (but less future-proof) fix could be to optimize your code so that even though it may cause your UI to hang, at least it won't be hanging for long. **insert your favorite troll emoji here** My guess is that your code is trying to gather information it doesn't need or calculate things it should already know (for instance the load more button should not have to reload any information that's already loaded, but should instead opt to reuse the information that it calculated beforehand). It is likely why it takes longer and longer to load with each click of the load more button. "Load more" may actually mean "load it again and more" for your code.

[BitBlitObviMormon]

With that last paragraph in mind this is probably also related to issue #3.

[NirmalScaria]

The performance issue caused due to higher number of branches has been listed as a new issue, since that would require a completely different way of approaching. That issue is due to the lack of required APIs from GitHub, and would require some hacks/workarounds. It can be tracked at #41