Это преждевременная оптимизация для разработки на медленных машинах?
Мы должны развиваться на медленных боксенах, потому что это заставляет нас оптимизировать рано.
Рэндалл Хайд отмечает, что в книге "Ошибка преждевременной оптимизации" существует множество заблуждений относительно цитаты Хоара:
Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла.
В частности, хотя машины в наши дни кричат по сравнению с машинами во времена Хоара, это не означает, что "оптимизации следует избегать". Так есть ли у моего уважаемого коллеги момент, когда он предлагает нам развиваться на скромных темпах? Идея состоит в том, что узкие места производительности являются более раздражающими на медленной коробке, и поэтому они, вероятно, привлекут внимание.
9 ответов
Медленные компьютеры не помогут вам найти проблемы с производительностью.
Если ваши тестовые данные находятся всего в нескольких сотнях строк в таблице, ваша БД будет кэшировать их все, и вы никогда не найдете плохо написанных запросов или неверного дизайна таблиц / индексов. Если ваше серверное приложение не является многопоточным, вы не узнаете об этом, пока не проведете стресс-тестирование с 500 пользователями. Или если приложение узкое место в пропускной способности.
Оптимизация - это "хорошая вещь", но, как я говорю новым разработчикам, у которых есть всевозможные идеи о том, как сделать это лучше "Мне все равно, как быстро вы дадите мне неправильный ответ". Сначала сделайте это правильно, а затем сделайте это быстрее, когда найдете узкое место. Опытный программист собирается спроектировать и построить его достаточно хорошо для начала.
Если производительность действительно критична ("миллисекундные транзакции" в режиме реального времени), то вам необходимо разработать и внедрить набор тестов и инструментов, чтобы с научной точки зрения доказать себе, что ваши изменения делают это быстрее. Существует слишком много переменных, которые влияют на производительность.
Плюс есть классическое оправдание программиста, которое они приведут - "но он работает медленно, потому что мы специально выбрали медленные компьютеры, он будет работать намного быстрее, когда мы развернем его".
Если ваш коллега считает это важным, дайте ему медленный компьютер и возложите на него ответственность за "производительность":-)
Это должна быть вики сообщества, так как она довольно субъективна и "правильного" ответа нет.
Тем не менее, вы должны разрабатывать на самой быстрой машине, доступной вам. Да, все, что медленнее, вызовет раздражение и побудит вас исправить замедления, но только по очень высокой цене:
Ваша производительность как программиста напрямую связана с количеством вещей, которые вы можете держать в своей голове, и все, что замедляет ваш процесс или вообще мешает вам, удлиняет время, которое вам нужно для того, чтобы хранить эти идеи в кратковременной памяти, делая Вы, скорее всего, забудете их, и вам придется заново изучать их.
Ожидание компиляции программы позволяет стеку ошибок, потенциальных проблем и исправлений выпадать из вашей головы, когда вы отвлекаетесь. Ожидание загрузки диалогового окна или запроса на завершение аналогично прерывает вас.
Даже если вы проигнорируете этот эффект, вы все равно поймете правду о последнем утверждении - ранняя оптимизация заставит вас гоняться за кругами, ломать код, который уже работает, и угадывать (часто с низкой точностью), где что-то может застрять вниз. Во-первых, правильно спроектируйте свой код, и вы можете забыть об оптимизации, пока у него не будет возможности немного согласиться, и в этот момент любая необходимая оптимизация станет очевидной.
Я думаю, это будет зависеть от того, что вы делаете и какова целевая аудитория.
Если вы пишете программное обеспечение для стационарного оборудования (скажем, для консольных игр), тогда используйте оборудование (по крайней мере, тестовое оборудование), которое похоже или совпадает с тем, на котором вы будете устанавливать.
Если вы разрабатываете настольные приложения или что-то в этом роде, то разрабатывайте их на любом желаемом компьютере, а затем настраивайте его для запуска на желаемом оборудовании минимальной спецификации. Аналогичным образом, если вы разрабатываете собственное программное обеспечение, вероятно, будет минимальная спецификация для машин, которые компания хочет купить. В этом случае, разработайте на быстрой машине (чтобы сократить время разработки и, следовательно, затраты) и протестируйте эту минимальную спецификацию.
В итоге разработайте на самой быстрой машине, которую вы можете получить, и протестируйте минимальное или точное оборудование, которое вы будете поддерживать.
Если вы программируете на оборудовании, близком к финальной тестовой и производственной средам, вы обнаружите, что, когда приходит время выпустить код, возникают менее неприятные сюрпризы.
Я видел достаточное количество программистов, которые сталкивались с серьезными, но неожиданными проблемами, вызванными тем, что их машины работали быстрее, чем большинство их пользователей. Но я также видел ту же проблему с данными. Код проверяется на небольшом наборе данных, а затем "крошится" на большом.
Любые различия в средах разработки и развертывания могут стать источником неожиданных проблем.
Тем не менее, поскольку программирование является дорогостоящим и трудоемким, если конечный пользователь использует медленное устаревшее оборудование, лучшее решение состоит в том, чтобы справиться с ним во время тестирования (и запланировать в нескольких ранних тестах просто для проверки удобства использования и время).
Зачем калечить ваших программистов только потому, что вы боитесь упустить потенциальную проблему? Это не вменяемая стратегия развития.
Павел.
Оптимизации следует избегать, разве это не дает нам Vista?:п
Но на полном серьезе, это всегда вопрос компромиссов. Важные вопросы, чтобы задать себе
Какую платформу будут использовать ваши конечные пользователи? Могу ли я сбросить циклы? Что будет, если я сделаю?
Я согласен с большинством, что начальная разработка должна быть сделана на самой быстрой или самой эффективной (не обязательно той же) машине, доступной вам. Но для запуска тестов, запустите его на целевой платформе, и тестируйте часто и рано.
Ради любви к Кодду, используйте инструменты профилирования, а не медленные машины разработки!
Я думаю, что это разумная концепция (но, возможно, потому что она работает для меня).
Если моя рабочая станция для разработчиков работает слишком быстро, я нахожу, что я недостаточно обдумываю идеи просто потому, что при повторной генерации образа программного обеспечения или его загрузке в конечную точку времени не хватает. Я бы сказал, что по крайней мере половина моих загрузок была ненужной, потому что я только что вспомнил кое-что, что я пропустил прямо перед тем, как собирался отлаживать код.
Целевая машина вполне может содержать дроссельный процессор. Если - на встроенном MCU - у вас есть половина FLASH, RAM и тактовых циклов в секунду, то есть шансы, что разработчики будут более осторожны при разработке своего кода. Однажды я предложил байтовые переменные для длин отдельных записей в области данных (не в ОЗУ, а в последовательном EEPROM) и получил ответ "нам не нужно скупиться". Через несколько месяцев они достигли потолка оперативной памяти (128 КБ). Я подумал, что для этого приложения никогда не будет записей размером более 256 байт просто потому, что не было ОЗУ для их копирования.
Я думаю, что для серверных приложений было бы неплохо иметь (гораздо) менее производительное оборудование для тестирования. Два или четыре ядра вместо шестнадцати (или более). 1,6 ГГц istdo 2.8. Список можно продолжить. Сервер обычно - из-за самого факта, что все говорят с ним - узкое место в архитектуре системы. И это задолго до того, как вы начнете разрабатывать (серверное) приложение для него.
Я, как правило, развиваюсь на самой быстрой машине, которую могу достать.
Большую часть времени я запускаю отладочную сборку, которая уже достаточно медленная.
Зависит от вашего времени доставки. Если вы находитесь в 12-месячном цикле поставки, то вам следует разработать коробку с приличной скоростью, так как через 12 месяцев ваши клиенты будут иметь "средние" коробки лучше, чем текущее "среднее".
Поскольку ваш цикл разработки приближается к "сегодняшнему", ваши машины разработки должны приближаться к текущей "средней" скорости коробок ваших клиентов.