Инструменты для диагностики причин медленной компиляции / сборки - PullRequest
Новая
       17

Инструменты для диагностики причин медленной компиляции / сборки

4 голосов
/ 18 декабря 2009

В ряде ситуаций, будучи программистом, я обнаружил, что время компиляции у меня меньше, чем хотелось бы, и я хочу понять причину и исправить ее. Особые языковые приемы (да, я использую C / C ++) уже обсуждались, и мы применяем многие из них. Я также видел этот вопрос и понимаю, что он связан. Больше всего меня интересует, какие инструменты люди используют для диагностики узких мест оборудования / системы в процессе сборки. Существует ли стандартный способ доказать: «Чтение / запись на диск слишком медленная для наших сборок - нам нужны SSD!» или «Настройки антивируса убивают наше время сборки!» и т. д ...?

Ресурсы, которые я нашел, но ни один из них не имеет прямого отношения к диагностике производительности:

  • Статья TechNet об использовании PerfMon ( Довольно хорошо, близко к тому, что я хотел бы)
  • Эта ссылка IBM с подробной информацией о PerfMon, но она не относится к компиляции и выглядит несколько устаревшей.
  • Веб-страница , конкретно описывающая диагностику средней очереди диска

В настоящее время диагностика медленной сборки - это искусство, и я выбрал следующие инструменты:

Что делают другие для диагностики узких мест производительности сборки на системном уровне? Можем ли мы получить список статистики PerfMon или Process Explorer, за которой нужно следить, с порогами того, что «приемлемо» на современном компьютере?

PerfMon:

  • CPU ->% времени процессора
  • ПАМЯТЬ -> Страница / сек
  • ДИСК -> Ср. длина очереди диска

Process Explorer:

  • CPU -> CPU
  • ДИСК -> Итого ввода / вывода
  • ПАМЯТЬ -> Ошибки страницы

Ответы [ 2 ]

0 голосов
/ 25 марта 2011

Я использовал filemon для просмотра файлов заголовков, которые чаще всего открывал сборка C ++:

  • «# ifndef проверяет», поэтому заголовочные файлы включаются только один раз
  • Предварительно скомпилированные заголовки
  • Объединено несколько небольших заголовочных файлов
  • Уменьшите количество файлов заголовков, включенных в другие файлы заголовков, приведя в порядок код.

Однако в наши дни я бы начал с RamDisk и / или SSD, , но для открытия большого количества заголовочных файлов все еще используется много процессорного времени .

0 голосов
/ 18 декабря 2009

Недавно я решил проблему с «слишком медленной сборкой» в Eclipse и Spring. Для меня решение состояло в том, чтобы использовать Vista Resource Monitor (который идентифицировал скачки ЦП, но не всегда высокий) и довольно немного активности диска. Затем я использовал Procmon из Sysinternals , чтобы точно определить, к каким файлам обращались.

Часть нашего процесса сборки также включает проверку внешних репозиториев Maven (двоичный файл) на наличие обновлений при каждой сборке. Я отключил эту проверку (что также дает мне полный контроль над обновлением этих зависимостей). Если у вас есть ресурсы, внешние по отношению к машине сборки, отметьте, сколько времени требуется для доступа к ним (управление исходным кодом, maven и т. Д.).

Поскольку я пока что застрял на 32-битной Vista, я решил попробовать создать Ramdisk с 700 МБ неадресуемой памяти (на ПК 4 ГБ, Vista имеет только 3,3 ГБ) и разместить файлы с большим доступом, как указано Procmon на Ramdisk использовал хороший трюк для создания соединений дисков, чтобы сделать этот переход прозрачным для моей IDE. Подробнее см. Здесь .

...