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


Visual Studio - wydajność

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.