Paweł Łukasiewicz
2016-07-28
Paweł Łukasiewicz
2016-07-28
Wprowadzenie
Ostatnio w trakcie wprowadzania poprawek w starszych projektach zauważyłem ogromny spadek wydajności działania Visual Studio 2010. W internecie możemy natknać się na wiele sposobów rozwiązania tego problemu, jednakże nie były one zawarte w jednym artykule. W przypadku mojego środowiska skuteczne okazały się instrukcje z n-tego artykułu. Dlatego poniżej zostaną zebrane i zestawione najcześciej polecane rozwiąznia (w tym to, które było skuteczne w moim przypadku).
Sposób 1
W pierwszej kolejności idziemy do następujących ustawień:
Tools -> Options -> Environment -> General -> Visual Experience
a następnie odznaczamy:
Automatically adjust visual experience based on client performance
oraz
Use graphics hardware acceleration if available
W moim przypadku nie zauważyłem żadnej zmiany – instrukcje te były jednak komentowane jako pomocne dla wielu użytkowników.
Sposób 2
Kolejne powszechnie komentowane rozwiązanie dotyczyło skasowania folderów tymczasowych. Dwie wspomniane ścieżki dotyczyły usunięcia folderów z poniższych lokalizacji:
- C:\Users\NazwaTwojegoUzytkownika\AppData\Local\Microsoft\WebSiteCache
- C:\Users\NazwaTwojegoUzytkownika\AppData\Local\Temp\Temporary ASP.NET
To rozwiązanie również nie przyniosło oczekiwanych skutów w przypadku mojego środowiska - musiałem szukać dalej…
Sposób 3
Następne sugerowane rozwiązanie skupiało się na usunięciu plików .sdf oraz .sou o takiej samej nazwie jak nazwa Twojego projektu.
Jeżeli nazwa Twojego projektu to:
c:\MyProject\project.sln
należy usunąć następujące pliki:
- c:\MyProject\project.sdf
- c:\MyProject\project.sou
Według komentarzy skasowanie tych plików rozwiązuje 98% problemów z wydajnością Visual Studio 2010. Pliki te zawierają informacje, które nie są istotne dla funkcjonalności Twojego projektu, jednakże wraz z rozwojem projektu znacząco zwiększają swoją objętość. Środowisko opiera się na tych plikach i jeżeli ich przetwarznie jest powolne, wówczas działanie całego Visual Studio również staje się powolne.
Co do skuteczności rozwiązania...musiałem być w pozostałych 2%...
Sposób 4
Aż wreszcie trafiłem na, wydawać by się mogło, najbardziej banalne rozwiązanie. Należało usunać wszystkie breakpoint'y oraz zamknąć wszystkie pootwierane zakładki. Projekt, który wcześniej wspomniałem, skada sie z około 20 podprojektów, jest wpierany przez moją osobę od około 2 lat, dlatego nie można się dziwić ilości ustawionych breakpoint'ów oraz ilości otwartych zakładek. W każdym razie to rozwiązanie okazało się skuteczne a VS powróciło do swojej dawnej wydajności.