У меня была проблема, когда для загрузки решения более 100 проектов требовалось более 10 минут. После загрузки VS производительность будет в порядке, хотя она будет странно колебаться между нормальным и очень плохим.
Краткий ответ: устранение предупреждений Resharper, похоже, улучшает общую производительность VS / R #.
Самая большая проблема в конечном итоге заключалась в том, что у нас было несколько файлов двоичных данных (зашифрованных данных), включаемых в качестве встроенных ресурсов, которые, как оказалось, имели расширения .xml. Решарпер действительно очень старался проанализировать эти файлы. В конце концов, он прошел бы, но в процессе генерировал бы 100K + ошибок. Изменение расширения на одно Resharper не привело к автоматическому анализу (в данном случае .bin), что решило проблему.
У нас все еще есть около 10 файлов, которые, когда они или файл, от которого они зависят, некоторое время редактируются. Эти файлы являются частичными частями одного определения класса, где каждый файл в среднем 3000 LOC. Да, верно, речь идет о классе линии 30К. Это также оказывается довольно плохим кодом по другим причинам, многие из которых помечают Resharper, делая правую полосу желоба практически сплошной оранжевой линией. Редактирование часто заставляет Resharper заново проанализировать все это. Пока этот анализ выполняется, производительность заметно снижается.
Я пришел к выводу, что чем меньше ошибок / предупреждений для R #, тем лучше он работает. Мои неподтвержденные доказательства, собранные во время очистки / рефакторинга этого проекта, похоже, подтверждают его.
Многие люди жалуются на проблемы с перфорированием с Решарпером. Если у вас есть даже несколько больших уродливых файлов кода с большим количеством предупреждений Resharper, то небольшое время, потраченное на очистку этого кода, может повысить общую производительность. Это для нас.