-
Notifications
You must be signed in to change notification settings - Fork 69
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
Speedup browsing huge patches - show changes for single files. #125
base: master
Are you sure you want to change the base?
Conversation
…xt exceeds configured limit. Added configuration option "Max patch size MiB". If size of patch text exceeds that limit - PatchContent splits it into per-file change and shows changes for each selected file separately. Otherwise - no changes, will be shown entire patch content.
411fb92
to
01542eb
Compare
Thank you for the useful functionality. A few issues:
Please, give an example of a repository containing very big diffs, on which I could inspect the observed slowness issue. Thanks again |
I run into this bug occasionally so I've applied a simplified version of this patch (without settings configuration) to my repository with a hardcoded 400KiB limit. At that size the pause is a couple seconds on my system. This repository has a variety of large commits that can be used for testing: https://github.com/huxingyi/dust3d
|
Hello Karl Thanks for the test repo example and for the report on the behaviour of your patch. Alexei, Do you have comments on my previous notes from the reply of 2022-02-25? I don't see any additional changes in your forked repo (although you mention a simplified version above). Am I looking in the wrong place? |
The change was to my local repo, but I've now pushed it to https://github.com/WickedSmoke/qgit/tree/large_patch. Note that patchcontent.h is unchanged from Aleksei's code, so the comments there are not accurate. Ideally this would be fixed in a way that prevents the slowdown from ever occurring and without any work-around settings. It may need to be considered along with Log/Diff tab changes of #44, #85, & #105. Other Git browsers handle this by keeping all diffs in one view, but collapsing the diff of individual files which are too large. This would work with my preferred change of eliminating the tabs. Note that a short term solution of using my hardcoded largePatchBytes along with your recommend message in the "Diff" display would make this initial display unreachable after clicking on a file. The user would have to select another commit and re-select the desired one to see the list of changes again. |
I updated my large_patch branch with a "[Large Patch]" notice. Even with the caveat about the unreachable initial display, I think pushing something similar to master is preferable to the current behavior which makes the program unusable. |
With large patches next functions of PatchContent became so slow that app became unresponsive:
And if you select revision with huge patch in RevsView app eats 100% cpu core and freeze for seconds to minutes.
Then if you select file from FileList - then it hangs almost forever.
This patch makes PatchContent show changes only for selected file if size of patch text exceeds configured limit.
Added configuration option "Max patch size MiB".
If size of patch text exceeds that limit - PatchContent splits it into per-file change
and shows changes for each selected file separately.
Otherwise - no changes, will be shown entire patch content.