https://bugs.kde.org/show_bug.cgi?id=486949
--- Comment #9 from Igor Kushnir <igor...@gmail.com> --- (In reply to Zamundaaa from comment #8) > Interestingly, I'm currently doing stuff in Mesa (which uses Meson), and > while it still hangs for a second, it's responsive again way sooner than in > KWin, despite being a larger project with more files. I think the extent of the slowdown depends on how long the git commands `git status` and `git ls-files` take. The slowdown for the KDevelop project was very significant on my system until recently. There had been a repository corruption caused by a system freeze, which produced an error message whenever I run `gitk --reflog`. But not anymore. I suspect that git garbage collection has run, got rid of corrupted objects and mitigated the slowdown tracked in this bug. I just found that connections to the VCS plugin's branch change are not unique. So if N git projects are open, the number of `git status` and `git ls-files` calls is multiplied by N. I'll fix this. Another thing I noticed is a slowdown when git-rebase applies many commits one after another. This is likely caused by the line `QTimer::singleShot(1000, this, &GitPlugin::delayedBranchChanged);` in GitPlugin::fileChanged(), which accumulates timers and emits repositoryBranchChanged() many times. I intend to fix this by reusing a single QTimer per git repository and restarting it in GitPlugin::fileChanged(). A more complicated issue is that RepoStatusModel and ProjectChangesModel both run `git status` with the same parameters when something changes. Ideally, their code should be deduplicated and refactored so that `git status` is run only once. But that's much more difficult, especially because the Project Changes tool view seems utterly broken and would require a lot of work to fix. -- You are receiving this mail because: You are watching all bug changes.
