GitDiffMargin
GitDiffMargin copied to clipboard
laurentkempe
Noticeable delay in long files
I have to work with source code files that have some thousand lines to refactor them. When making changes to these files, it always takes a short time to update the diff bar, like half a second. During this time, no other input events are handled. So the editor becomes very stuttering and far from interactive with such files. I suspect that the diff computation happens on the UI thread of Visual Studio. If this is the case, it should be offloaded to another thread and made an async call.
I'm using the current version 3.2 of the extension in Visual Studio 2015 Update 3 on Windows 7 x64, with the latest Git version installed, currently 2.11.
There is no such delay with the extension disabled.
Thanks for the report @ygoe to the best of what I can remember computation happens on the background and not on UI thread!
Do you have lots of changes in the file, because the update of the UI might be the problem, that cannot be done on the background!
That may be the case as well. I'll retry on another large file before making changes. Yes, my refactoring work involves reshaping large parts of these files, so there are many changes.
I think you're right. I've tried it on a long file with only a few changes and there was no delay.
Would it be possible to detect such a delay from the extension and skip or delay the rendering in that case?
What's interesting is also that no such delays result from Visual Studio's own modified/saved bar (the yellow/green one). Maybe it generates more efficient geometries like combining multiple subsequent lines of the same colour into one rectangle?
Would it be possible to detect such a delay from the extension and skip or delay the rendering in that case?
What's interesting is also that no such delays result from Visual Studio's own modified/saved bar (the yellow/green one). Maybe it generates more efficient geometries like combining multiple subsequent lines of the same colour into one rectangle?
I thought it would be faster to compute only the elements which are on the visible part, but then we would loose the part on the right bar! So I am not sure at the moment, I need to reproduce your case to measure it and see what kind of solution we could have. Do you have a sample file that you could share to see the problem? Do you get that issue often?
Yes, the scrollbar "map" is also useful. Also, your idea might move the delays from editing to scrolling.
I only saw this issue when refactoring the large files in that project. But it should be reproducible if you generate a file with ~5000 alternating lines, commit, then alter every second line. Macro recording and find/replace should do the trick quickly.
generate a file with ~5000 alternating lines, commit, then alter every second line. Macro recording and find/replace should do the trick quickly
Ok I will try that kind of configuration, but honestly that's an edge case, we have at work some tests file with ~3500 lines but for sure we never alter every second line. One way would be to disable Git Diff Margin on a file while editing it.
Altering every second line is just a demo pattern. My refactoring affected lots of places, not on contiguous lines, and I had lots of coloured spots in the diff bar.
How would I disable the diff bar on single files? Or is that just a feature idea?
How would I disable the diff bar on single files? Or is that just a feature idea?
It is just an idea at the moment. I see it as a button that you could place on the Visual Studio Toolbar