GitDiffMargin
GitDiffMargin copied to clipboard
laurentkempe
VS2017: Dramatically slow down VS editor if many changes in edited file or repository.
After upgrade GIT from 2.15 to 2.16 GitDiffMargin dramatically slow down VS editor if many changes in file or files. After disabling plugin performance restored.
@sharky72 can you submit a performance report using the instructions on https://aka.ms/reportPerf? Then reply back here with a link to the feedback you created.
I am back from vacations so sorry for the late answer. @sharky72 Could you do what @sharwell proposed?
I'm sorry but currently, do not have time. I'll make a report little later and send information to you when it's done. Thanks.
I'm having similar issues with lag of text typing in VS 2017 Community. Seems to be more prevalent with intellisense. Windows 10 Pro, VS 2017 V15.6.5. Just feels a tad slower. But enough to make me disable plugin. I will record performance later today, after work.
@alexramsey92 Could you provide a performance report like @sharwell asked? Is your repository showing the issue public so that we could experience it ourselves too?
I also noticed that the performance absolutely tanks the more diff items it has on open files (guestimating 200-300+ individual margin entries). It occasionally gets to a point where I have to just stop and disable the plugin until after I commit.
I cannot submit a performance report from work but may be able to re-create it at home if I ever get around to it.
Yes, @PeterJeff 200-300+ diff is quite a lot, and the drawing is not optimized! One option would be to work on calculating only for the diff which are visible and virtualize the whole. This could be quite complex, so I avoided it.
Could you give some context about how do you end up with that amount of changes in one file?
I've definitely seen cases like that, but we worked to optimized them pretty well already. For this type of situation, the performance trace is the true conclusive data to get it identified and fixed.
200-300 would not be considered a particularly large number to me. I've seen 10,000+ following automated refactorings.