Как определить количество Вашей “медленной” машины разработки?
(Предоставьте вопросу эти дубликаты. Я разочарован, я не мог найти его.)
Моя машина разработки является "медленной". Я ожидаю на нем "много".
Меня спросили лица, принимающие решения, которые хотят помочь к справедливо и точно измерить то время. Как Вы определяете количество количества времени, которое Вы тратите ожидание на компьютер (во время компиляций, ожидания приложений для открытия каждый день, и т.д.).
Есть ли программное обеспечение, которое эффективно сообщает относительно этого вида вещи? Существует ли метрика ОС (ввод-вывод что-то что-то, частота свопинга файла подкачки, и т.д., и т.д.), который получает и передает это особенно хорошо? Своего рода сравнительный тест Вы рекомендовали бы мне тестирующий против?
Править: Я пишу C# (главным образом ASP.NET).
5 ответов
Вот один показатель, который может впечатлить некоторых руководителей: измерьте среднее время, необходимое для создания вашего приложения, и сколько раз вы делаете это в день. Например, у нас получилось около 100 сборок в день по 60 секунд каждая. Теперь измерьте среднее время сборки на предположительно более быстрой машине (скажем, 30 секунд на сборку).
Теперь вы можете увидеть, сколько времени вы бы сэкономили, если бы приобрели «более быструю» машину. На разработчика, в день. Умножьте на количество разработчиков и количество дней в месяце, и вы увидите, как это сочетается с добавлением еще одного разработчика в команду. Да, я знаю, есть и другие соображения при добавлении новых людей в команду, но это даст вам грубое сравнение, к которому могут относиться «более высокие». Например: если бы у всех нас были более быстрые машины, мы бы тратили меньше времени на сборки, сравнимо с одним дополнительным разработчиком.
С другой стороны, вы должны дать точную оценку стоимости обновления каждой машины.
Теперь, если вы можете, вам следует запустить этот тип сравнения с несколькими «более быстрыми» машинами, чтобы определить их относительную производительность и, возможно, выделить узкие места, с которыми вы сталкиваетесь (RAM против CPU против ввода-вывода?).
Наконец, я лично считаю, что, пока имеет место такой процесс и последующее обсуждение с заинтересованными сторонами (и это может занять некоторое время), вы могли бы получить у всех больше / больше мониторов. Это относительно дешевое обновление (конечно, не такое уж дешевое, если вы выберете 52-дюймовые ЖК-мониторы, не так ли?), И большее количество мониторов действительно улучшает производительность (совет: также улучшает моральный дух сотрудников, что, в свою очередь, повышает производительность)
HTH
Зависит от вашей рабочей среды. Например. в Visual Studio (C ++, 2005) вы можете выполнять сборки по времени, так что IDE печатает прошедшее время после обычных выходных данных сборки.
Закройте FireFox, чтобы получить немного памяти. Добавьте RAM. Мне очень помогли.
Количественная оценка затруднена, когда вам не с чем измерять / сравнивать. Если вашему блоку разработки требуется 12 минут для компиляции проекта из 100 000 строк кода без какого-либо другого блока разработки, с которым можно было бы сравнивать, вы понятия не имеете, хорошо это или плохо. Может быть, 12 минут на 100 000 строк - это действительно хорошо?
Измерение не поможет вам и, конечно, не поможет тем, кто принимает решения. Рассмотреть возможность; «Да, босс, на компиляцию нашего проекта уходит в среднем двенадцать минут». Босс говорит; «Хорошо, это нормально?». У тебя нет идей.
Компьютерное оборудование дешевое. Посмотрите на коробку разработчика и подумайте о том, чтобы попросить лиц, принимающих решения, потратить на нее немного денег, чтобы улучшить ее производительность. Если вы компилируете в среднем 5 раз в день и на компиляцию уходит в среднем 12 минут, это потерянный час каждый день - в сумме до 5 потерянных часов в неделю. Стоит потратить немного оперативной памяти или обновление процессора.
Для меня медленная машина не убивает производительность так сильно, как неожиданное замедление - если машина компилирует все решение за 12 минут при каждом нажатии F5, в решении какая-то проблема, а не в машине. Кроме того, у меня нет проблем с 12 минутами, я могу встать и сделать перерыв. На самом деле хорошо делать перерыв, когда вы знаете и контролируете его продолжительность.
Я обнаружил, что больше всего убивают продуктивность это совместное программное обеспечение, которое начинает сканировать вирусы (или устанавливать обновления) по своему желанию - сидеть и ждать - это утомительно.