Используйте распределенную компиляцию. Xoreax IncrediBuild может сократить время компиляции до нескольких минут.

Я использовал его в огромном решении C \ C++, компиляция которого обычно занимает 5-6 часов. IncrediBuild помог сократить это время до 15 минут.

Первоначально я разместил этот ответ здесь: https://stackoverflow.com/questions/8440/visual-studio-optimizations#8473 Вы можете найти много других полезных советов на этой странице.

Если вы используете Visual Studio 2008, вы можете скомпилировать с помощью флага / MP для параллельной сборки одного проекта. Я читал, что это тоже недокументированная функция в Visual Studio 2005, но никогда не пробовал.

Вы можете строить несколько проектов параллельно, используя флаг / M, но обычно он уже установлен на количество доступных ядер на машине, хотя я считаю, что это применимо только к VC++.

Возможно, возьмите некоторые общие функции и сделайте несколько библиотек, чтобы одни и те же исходники не компилировались снова и снова для нескольких проектов.

Если вас беспокоит, что разные версии DLL перепутаются, используйте статические библиотеки.

Если это C или C++, и вы не используете предварительно скомпилированные заголовки, вам следует их использовать.

Если это веб-приложение, установка для пакетной сборки значения true может помочь в зависимости от сценария.

<compilation defaultLanguage = "c#" debug = "true" batch = "true" >  

Вы можете найти обзор здесь: http://weblogs.asp.net/bradleyb/archive/2005/12/06/432441.aspx

Отключите интеграцию VSS. У вас может не быть выбора в его использовании, но библиотеки DLL все время «случайно» переименовываются ...

И обязательно проверьте настройки предварительно скомпилированного заголовка. Руководство Брюса Доусона немного устарело, но все же очень хорошее - проверьте: http://www.cygnus-software.com/papers/precompiledheaders.html

У меня есть проект, который имеет 120 или более exes, libs и dll и требует значительного времени для создания. Я использую дерево пакетных файлов, которое вызывает создание файлов из одного основного пакетного файла. В прошлом у меня были проблемы со странностями из инкрементных (или они были темпераментными) заголовками, поэтому сейчас я их избегаю. Я делаю полную сборку нечасто и обычно оставляю ее на конец дня, пока гуляю час (так что могу только догадываться, что это займет около получаса). Так что я понимаю, почему это невозможно для работы и тестирования.

Для работы и тестирования у меня есть другой набор командных файлов для каждого приложения (или модуля или библиотеки), в которых также есть все настройки отладки, но они по-прежнему вызывают одни и те же файлы make. Я могу время от времени отключать DEBUG, а также принимать решение о сборках или изготовлении, или хочу ли я также создавать библиотеки, от которых может зависеть модуль, и так далее.

Пакетный файл также копирует готовый результат в (или в несколько) тестовых папок. В зависимости от настроек это занимает от нескольких секунд до минуты (а не полчаса).

Я использовал другую среду IDE (Zeus), так как мне нравится контролировать такие вещи, как файлы .rc, и на самом деле я предпочитаю компилировать из командной строки, хотя я использую компиляторы MS.

С радостью выложу пример этого командного файла, если кому-то интересно.

Одна более дешевая альтернатива Xoreax IB - это использование так называемых сборок сверхфайловых файлов. По сути, это файл .cpp с

#include "file1.cpp"
#include "file2.cpp"
....
#include "fileN.cpp"

Затем вы компилируете модули uber вместо отдельных модулей. Мы видели время компиляции от 10-15 минут до 1-2 минут. Возможно, вам придется поэкспериментировать с тем, сколько #includes в uber-файле имеет смысл. Зависит от проектов. и т.д. Может быть вы включаете 10 файлов, может быть, 20.

Вы платите определенную сумму, поэтому будьте осторожны:

1. Вы не можете щелкнуть файл правой кнопкой мыши и сказать «скомпилировать ...», так как вам нужно исключить отдельные файлы cpp из сборки и включить только файлы uber cpp
2. Вы должны быть осторожны с конфликтами статических глобальных переменных.
3. Когда вы добавляете новые модули, вы должны поддерживать файлы uber в актуальном состоянии.

Это своего рода боль, но для проекта, который в значительной степени статичен с точки зрения новых модулей, первоначальная боль может того стоить. Я видел, как этот метод в некоторых случаях превосходил IB.

Команда Chromium.org перечислила несколько вариантов для ускорение сборки (на этом этапе примерно на полпути вниз по странице):

In decreasing order of speedup:

• Install Microsoft hotfix 935225.
• Install Microsoft hotfix 947315.
• Use a true multicore processor (ie. an Intel Core Duo 2; not a Pentium 4 HT).
• Use 3 parallel builds. In Visual Studio 2005, you will find the option in Tools > Options... > Projects and Solutions > Build and Run > maximum number of parallel project builds.
• Disable your anti-virus software for .ilk, .pdb, .cc, .h files and only check for viruses on modify. Disable scanning the directory where your sources reside. Don't do anything stupid.
• Store and build the Chromium code on a second hard drive. It won't really speed up the build but at least your computer will stay responsive when you do gclient sync or a build.
• Defragment your hard drive regularly.
• Disable virtual memory.

Вы также можете проверить наличие циклических ссылок на проекты. Однажды для меня это было проблемой.

То есть:

Проект A ссылается на проект B

Проект B ссылается на проект C

Проект C ссылается на проект A

Хорошие предложения, которые помогли до сих пор (не говоря уже о том, что ниже нет других хороших предложений, если у вас есть проблемы, я рекомендую прочитать то, что нам помогло)

• Новый ноутбук с тактовой частотой 3 ГГц - сила потери нагрузки творит чудеса, когда мы обращаемся к руководству
• Отключить антивирус во время компиляции
• `` Отключение '' от VSS (фактически от сети) во время компиляции - я могу заставить нас полностью удалить интеграцию VS-VSS и придерживаться пользовательского интерфейса VSS.

По-прежнему не копирует компиляцию, но помогает каждый бит.

Мы также тестируем практику создания новых областей приложения в новых решениях, при необходимости импортируя новейшие библиотеки DLL и интегрируя их в более крупное решение, когда мы довольны ими.

Мы также можем сделать то же самое с существующим кодом, создав временные решения, которые просто инкапсулируют области, над которыми нам нужно работать, и выбрасывая их после реинтеграции кода. Нам нужно взвесить время, необходимое для реинтеграции этого кода, и время, которое мы выиграем, не имея опыта быстрой перекомпиляции в процессе разработки, как у Рип Ван Винкля.

Орион упомянул в комментарии, что дженерики тоже могут сыграть свою роль. Мои тесты показывают, что производительность минимальна, но недостаточно высока, чтобы быть уверенным - время компиляции может быть нестабильным из-за активности диска. Из-за ограничений по времени мои тесты не включали столько универсальных шаблонов или столько кода, сколько могло бы появиться в реальной системе, так что это могло накапливаться. Я бы не стал избегать использования дженериков там, где они должны использоваться, только для производительности во время компиляции.

Выключите антивирус. Это увеличивает время компиляции.

У нас было более 80 проектов в нашем основном решении, создание которых занимало от 4 до 6 минут, в зависимости от того, на какой машине работал разработчик. Мы посчитали, что это слишком долго: каждый тест действительно съедает ваши FTE.

Итак, как сократить время сборки? Как вы, кажется, уже знаете, время сборки сильно ухудшает количество проектов. Конечно, мы не хотели избавляться от всех наших проектов и просто объединять все исходные файлы в один. Но у нас было несколько проектов, которые мы, тем не менее, могли объединить: поскольку каждый «проект репозитория» в решении имел свой собственный проект unittest, мы просто объединили все проекты unittest в один проект global-unittest. Это сократило количество проектов примерно до 12 и каким-то образом сэкономило 40% времени на создание всего решения.

Однако мы думаем о другом решении.

Вы также пробовали настроить новое (второе) решение с новым проектом? Это второе решение должно просто включать все файлы, использующие папки решения. Потому что вы можете быть удивлены, увидев время сборки этого нового решения с одним проектом.

Однако работа с двумя разными решениями требует особого внимания. Разработчики могут быть склонны фактически работать во втором решении и полностью игнорировать первое. Поскольку первое решение с более чем 70 проектами будет решением, которое заботится о вашей иерархии объектов, это должно быть решение, в котором ваш сервер сборки должен запускать все ваши модульные тесты. Таким образом, сервер для непрерывной интеграции должен быть первым проектом / решением. Вы должны поддерживать свою объектную иерархию, верно.

Второе решение с одним проектом (который будет строиться намного быстрее) будет, чем проект, в котором тестирование и отладка будут выполняться всеми разработчиками. Однако вы должны позаботиться о них, глядя на сервер сборки! Если что-то сломается, это ДОЛЖНО быть исправлено.

Убедитесь, что ваши ссылки являются ссылками на проекты, а не непосредственно на библиотеки DLL в выходных каталогах библиотеки.

Кроме того, установите для них запрет на локальное копирование, кроме случаев крайней необходимости (главный проект EXE).

Отключите индексирование файловой системы в ваших исходных каталогах (в частности, в каталогах obj, если вы хотите, чтобы ваш источник был доступен для поиска)

У меня была аналогичная проблема с решением с 21 проектом и 1/2 миллиона LOC. Самая большая разница заключалась в получении более быстрых жестких дисков. Из монитора производительности «Сред. Disk Queue 'значительно увеличился бы на ноутбуке, указывая на то, что жесткий диск был бутылочным горлышком.

Вот некоторые данные об общем времени восстановления ...

1) Ноутбук, Core 2 Duo 2 ГГц, привод 5400 об / мин (не уверен в кеш-памяти. Был стандартным Dell inspiron).

Время восстановления = 112 секунд.

2) Настольный компьютер (стандартная версия), Core 2 Duo 2,3 ГГц, один диск 7200 об / мин, 8 МБ кэш-памяти.

Время восстановления = 72 секунды.

3) Desktop Core 2 Duo 3Ghz, одиночный WD Raptor, 10000 об / мин

Время восстановления = 39 секунд.

Привод на 10 000 об / мин нельзя недооценивать. Сборки были значительно быстрее, плюс все остальное, например, отображение документации, использование файлового проводника было заметно быстрее. Это был большой прирост производительности за счет ускорения цикла код-сборка-выполнение.

Учитывая, сколько компании тратят на зарплату разработчиков, это безумный, сколько они могут потратить на покупку того же ПК, что и администратор.

Конечно, есть проблема с VS2008. Потому что единственное, что я сделал, - это установил VS2008 для обновления моего проекта, созданного с помощью VS2005. В моем решении всего 2 проекта. Он не большой. Компиляция с VS2005: 30 секунд Компиляция с VS2008: 5 минут

Если это проект C++, вам следует использовать предварительно скомпилированные заголовки. Это дает огромную разницу во времени компиляции. Не уверен, что на самом деле делает cl.exe (без использования предварительно скомпилированных заголовков), похоже, он ищет лоты заголовков STL во всех неправильных местах, прежде чем, наконец, перейти в правильное место. Это добавляет целые секунды к каждому компилируемому файлу .cpp. Не уверен, что это ошибка cl.exe или какая-то проблема STL в VS2008.

Глядя на машину, на которой вы строите, оптимально ли она сконфигурирована?

Мы только что получили время сборки нашего крупнейшего продукта корпоративного масштаба на C++ с 19 часов до 16 минут, убедившись, что установлен правильный драйвер фильтра SATA.

Тонкий.

Я заметил, что этому вопросу давно, но тема все еще актуальна. Та же проблема укусила меня в последнее время, и две вещи, которые больше всего улучшили производительность сборки: (1) использовать выделенный (и быстрый) диск для компиляции и (2) использовать одну и ту же папку вывода для всех проектов и установить CopyLocal на False в проекте Рекомендации.

Некоторые дополнительные ресурсы:

• https://stackoverflow.com/questions/8440/visual-studio-optimizations
• http://weblogs.asp.net/scottgu/archive/2007/11/01/tip-trick-hard-drive-speed-and-visual-studio-performance.aspx
• http://arnosoftwaredev.blogspot.com/2010/05/how-to-improve-visual-studio-compile.html
• http://blog.brianhartsock.com/2009/12/22/analyzing-visual-studio-build-performance/

В Visual Studio 2005 есть недокументированный переключатель / MP, см. http://lahsiv.net/blog/?p=40, который позволяет выполнять параллельную компиляцию на файловой основе, а не на основе проекта. Это может ускорить компиляцию последнего проекта или, если вы компилируете один проект.

Некоторые инструменты анализа:

инструменты-> параметры-> Настройки проекта VC++ -> Время сборки = Да сообщит вам время сборки для каждого vcproj.

Добавьте переключатель /Bt в командную строку компилятора, чтобы увидеть, сколько занимает каждый файл CPP

Используйте /showIncludes, чтобы перехватить вложенные включения (файлы заголовков, которые включают другие файлы заголовков) и посмотреть, какие файлы могут сэкономить много операций ввода-вывода с помощью предварительных объявлений.

Это поможет вам оптимизировать производительность компилятора, устранив зависимости и проблемы с производительностью.

Прежде чем тратить деньги на приобретение более быстрых жестких дисков, попробуйте создать свой проект полностью на RAM-диске (при условии, что у вас есть свободная RAM). Вы можете найти в сети различные бесплатные драйверы для RAM-диска. Вы не найдете ни одного физического диска, в том числе SSD, который был бы быстрее, чем RAM-диск.

В моем случае проект, на создание которого потребовалось 5 минут на 6-ядерном i7 на диске SATA 7200 об / мин с Incredibuild, был сокращен всего примерно на 15 секунд за счет использования RAM-диска. Учитывая необходимость повторного копирования в постоянное хранилище и возможность потери работы, 15 секунд - недостаточный стимул для использования RAM-диска и, вероятно, не большой стимул тратить несколько сотен долларов на высокоскоростной или SSD-накопитель.

Небольшой прирост может указывать на то, что сборка была привязана к ЦП или что кеширование файлов Windows было довольно эффективным, но поскольку оба теста проводились из состояния, когда файлы не были кэшированы, я сильно склоняюсь к компиляциям с привязкой к ЦП.

В зависимости от фактического кода, который вы компилируете, ваш пробег может отличаться, так что не стесняйтесь тестировать.

При выборе ЦП: размер кэша L1, похоже, имеет огромное влияние на время компиляции. Кроме того, обычно лучше иметь 2 быстрых ядра, чем 4 медленных. Visual Studio не очень эффективно использует дополнительные ядра. (Я основываю это на своем опыте работы с компилятором C++, но, вероятно, это также верно и для компилятора C#.)

Я также теперь убежден, что есть проблема с VS2008. Я запускаю его на двухъядерном ноутбуке Intel с 3G Ram, с выключенным антивирусом. Компиляция решения часто бывает довольно гладкой, но если я занимался отладкой, последующая перекомпиляция часто замедлялась до обхода. По непрерывному свету индикатора основного диска видно, что существует узкое место ввода-вывода на диске (вы также можете это услышать). Если я отменяю сборку и завершаю работу VS, активность диска прекращается. Перезапустите VS, перезагрузите решение, а затем перестройте, и это намного быстрее. Unitl в следующий раз

Я считаю, что это проблема с подкачкой памяти - VS просто заканчивается память, и O / S начинает подкачку страниц, чтобы попытаться освободить место, но VS требует больше, чем может дать подкачка страниц, поэтому он замедляется до обхода. Я не могу придумать другого объяснения.

VS определенно не является инструментом RAD, не так ли?

Насколько велик ваш каталог сборки после завершения сборки? Если вы придерживаетесь настройки по умолчанию, то каждая сборка, которую вы создаете, будет копировать все библиотеки DLL своих зависимостей и зависимостей зависимостей и т. д. В свой каталог bin. В моей предыдущей работе, когда я работал с решением для ~ 40 проектов, мои коллеги обнаружили, что самой дорогой частью процесса сборки было многократное копирование этих сборок, и что одна сборка может генерировать гигабайты копий одних и тех же библиотек DLL снова и снова. снова.

Вот несколько полезных советов от Патрика Смаккиа, автора NDepend, о том, что, по его мнению, должно и не должно быть отдельными сборками:

http://codebetter.com/patricksmacchia/2008/12/08/advices-on-partitioning-code-through-net-assemblies/

Есть два основных способа обойти эту проблему, и у обоих есть недостатки. Один из них - уменьшить количество сборок, что, очевидно, требует больших усилий. Другой вариант - реструктурировать каталоги сборки, чтобы все папки bin были объединены, а проекты не копировали библиотеки DLL своих зависимостей - в этом нет необходимости, потому что все они уже находятся в одном каталоге. Это значительно сокращает количество файлов, создаваемых и копируемых во время сборки, но это может быть сложно настроить и может вызвать некоторые трудности при извлечении только тех библиотек DLL, которые требуются конкретному исполняемому файлу для упаковки.

Есть несколько вещей, которые я нашел полезными для ускорения сборки C# / .NET:

• Объединяйте небольшие проекты в более крупные, поскольку создание решения сопряжено с большими накладными расходами на каждый проект. (Используйте nDepend, если необходимо управлять вызовами между уровнями)

• Сделайте так, чтобы все наши проекты были встроены в какой-либо выходной каталог, а затем установите для параметра «copy local» значение false для всех ссылок на проекты - это может привести к большому ускорению из-за сокращения операций ввода-вывода.

• Включите антивирусную программу, чтобы увидеть, насколько она важна; в таком случае найдите более быстрая проверка на вирусы или исключите "горячие" папки из проверки антивирусной программой.

• Используйте perforce monitor и внутренний инструмент sys, чтобы увидеть, как долго ваши компиляции занимают столько времени.

• Рассмотрим RAM-диск, на котором можно разместить выходной каталог.

• Рассмотрите возможность использования SSD

• Иногда больший объем памяти может иметь большое значение - (уменьшите количество плунжера в машине, если вы сильно замедлились, удалив небольшой плунжер, вы можете получить большую скорость, добавив больше) Удалите ненужные ссылки на проекты (возможно, сначала вам придется удалить ненужные «использования»)

• Рассмотрите возможность использования инфраструктуры внедрения зависимостей и интерфейсов для самого нижнего уровня домена, поэтому перекомпиляция всего требуется только при изменении интерфейса - это может не сильно выиграть в зависимости от того, как часто интерфейс изменяется.

Инструкции по сокращению времени компиляции Visual Studio до нескольких секунд

К сожалению, Visual Studio недостаточно умен, чтобы отличить изменения интерфейса сборки от несущественных изменений тела кода. Этот факт в сочетании с большим количеством взаимосвязанных решений может иногда создавать идеальный шторм нежелательных «полных сборок» почти каждый раз, когда вы меняете одну строку кода.

Стратегия преодоления этого - отключить автоматическое построение ссылочного дерева. Для этого используйте Configuration Manager (Build / Configuration Manager ... затем в раскрывающемся списке Active solution configuration выберите New), чтобы создать новую конфигурацию сборки под названием «ManualCompile», которая копирует из конфигурации Debug, но не устанавливайте флажок "Создать новые конфигурации проекта". В этой новой конфигурации сборки снимите флажки у всех проектов, чтобы ни один из них не собирался автоматически. Сохраните эту конфигурацию, нажав «Закрыть». Эта новая конфигурация сборки добавляется в ваш файл решения.

Вы можете переключиться с одной конфигурации сборки на другую с помощью раскрывающегося списка конфигурации сборки в верхней части экрана IDE (того, который обычно показывает либо «Отладка», либо «Выпуск»). Фактически эта новая конфигурация сборки ManualCompile сделает бесполезными пункты меню «Сборка» для: «Построить решение» или «Перестроить решение». Таким образом, когда вы находитесь в режиме ManualCompile, вы должны вручную построить каждый проект, который вы изменяете, что можно сделать, щелкнув правой кнопкой мыши каждый затронутый проект в обозревателе решений, а затем выбрав «Сборка» или «Перестроить». Вы должны увидеть, что общее время компиляции теперь будет составлять всего несколько секунд.

Чтобы эта стратегия работала, необходимо, чтобы VersionNumber, находящийся в файлах AssemblyInfo и GlobalAssemblyInfo, оставался статичным на компьютере разработчика (конечно, не во время сборок выпуска), и чтобы вы не подписывали свои библиотеки DLL.

Потенциальный риск использования этой стратегии ManualCompile заключается в том, что разработчик может забыть скомпилировать необходимые проекты, и при запуске отладчика они получают неожиданные результаты (невозможно подключить отладчик, файлы не найдены и т. д.). Чтобы избежать этого, вероятно, лучше всего использовать конфигурацию сборки Debug для компиляции большего объема кода и использовать конфигурацию сборки ManualCompile только во время модульного тестирования или для внесения быстрых изменений, которые имеют ограниченный объем.

У нас есть почти 100 проектов в одном решении, а время сборки составляет всего секунды :)

Для локальных сборок разработки мы создали надстройку Visual Studio, которая изменяет Project references на DLL references и выгружает нежелательные проекты (и, конечно же, возможность переключить их обратно).

• Соберите все наше решение однажды
• Выгрузите проекты, над которыми мы сейчас не работаем, и замените все ссылки на проекты ссылками на библиотеки DLL.
• Перед регистрацией измените все ссылки с DLL на ссылки проекта.

Наши сборки теперь занимают всего несколько секунд, когда мы работаем только над несколькими проектами одновременно. Мы также можем отлаживать дополнительные проекты, поскольку они связаны с отладочными библиотеками DLL. Инструмент обычно занимает 10-30 секунд, чтобы внести большое количество изменений, но вам не нужно делать это так часто.

Обновление май 2015 г.

Сделка, которую я заключил (в комментариях ниже), заключалась в том, что я выпущу плагин с открытым исходным кодом если, это вызывает достаточный интерес. Спустя 4 года у него всего 44 голоса (а у Visual Studio теперь есть две последующие версии), так что в настоящее время это проект с низким приоритетом.

Я обнаружил, что следующее помогает скорости компиляции: после многократных компиляций (итеративная разработка в памяти) я бы покинул VS2008. Затем перейдите в каталоги проекта и удалите все папки obj и bin, запустите проект обратно, и мое время компиляции резко упало. Это похоже на действие Clean solution в VS2008.

Просто хочу подтвердить, полезно ли это для кого-либо.

Я нашел свое исправление здесь: http://blogs.msdn.com/b/vsdteam/archive/2006/09/15/756400.aspx

Для сборок C# .NET вы можете использовать .NET Demon. Это продукт, который берет на себя процесс сборки Visual Studio, чтобы сделать его быстрее.

Он делает это путем анализа внесенных вами изменений и строит только тот проект, который вы действительно изменили, а также другие проекты, которые фактически основывались на внесенных вами изменениях. Это означает, что если вы измените только внутренний код, нужно будет построить только один проект.

Ваша компания случайно не использует Entrust для своего решения PKI / Encryption? Оказывается, у нас была ужасная производительность сборки для довольно большого веб-сайта, созданного на C#, что занимало 7+ минут на Rebuild-All.

Моя машина - i7-3770 с оперативной памятью 16 ГБ и SSD на 512 ГБ, поэтому производительность не должна быть такой плохой. Я заметил, что время моей сборки было безумно быстрее на старом вторичном компьютере с той же кодовой базой. Поэтому я запустил ProcMon на обеих машинах, профилировал сборки и сравнил результаты.

И вот, у медленной машины было одно отличие - ссылка на Entrust.dll в трассировке стека. Используя эту недавно полученную информацию, я продолжил поиск в StackOverflow и нашел это: MSBUILD (VS2010) очень медленный на некоторых машинах. Согласно принятому ответу проблема заключается в том, что обработчик Entrust обрабатывал проверки сертификатов .NET вместо собственного обработчика Microsoft. Также предполагается, что Entrust v10 решит эту проблему, которая преобладает в Entrust 9.

В настоящее время он удален, и время сборки упало до 24 секунды. YYMV с количеством проектов, которые вы в настоящее время создаете, и не может напрямую решать проблему масштабирования, о которой вы спрашивали. Я опубликую изменение этого ответа, если смогу предоставить исправление без, прибегнув к удалению программного обеспечения.

Низкая производительность Visual Studio… Решено! 24 сентября 2014 г., Узма Абиди

Сегодня у меня возникла странная проблема, связанная с производительностью. Моя Microsoft Visual Studio, похоже, занимала слишком много времени, чтобы выполнять даже самые простые операции. Я погуглил и попробовал несколько идей, которые были у людей, такие как отключение надстроек или очистка списка последних проектов Visual Studio, но эти предложения, похоже, не помогли решить проблему. Я вспомнил, что на веб-сайте Windows SysInternals есть инструмент под названием Process Monitor, который отслеживал доступ к реестру и файлам любой запущенной программой. Мне казалось, что Visual Studio что-то замышляет, и Process Monitor должен помочь мне понять, что это было. Я загрузил самую последнюю версию и, немного поигравшись с фильтрами отображения, запустил ее и, к своему ужасу, увидел, что Visual Studio работает так медленно, потому что имеет доступ к более чем 10 000 папок в C: \ Users \ krintoul \ AppData \ Local \ Microsoft \ WebSiteCache для большинства операций IDE. Я не уверен, почему было так много папок и, более того, я не знал, что Visual Studio делает с ними, но после того, как я заархивировал эти папки и переместил их в другое место, производительность Visual Studio значительно улучшилась.

На веб-сайте Windows SysInternals есть ряд других полезных утилит для управления сетью, безопасности, системной информации и многого другого. Проверить это. Я уверен, что ты найдешь что-нибудь ценное.