Это преждевременная оптимизация для разработки на медленных машинах?

Question

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

Рэндалл Хайд указывает на Ошибка преждевременной оптимизации , существует множество заблуждений относительно цитаты Хоара:

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

В частности, хотя машины в наши дни кричат ​​по сравнению с машинами во времена Хоара, это не означает, что «оптимизации следует избегать». Так есть ли у моего уважаемого коллеги момент, когда он предлагает нам развиваться на скромных темпах? Идея состоит в том, что узкие места производительности более раздражают на медленной коробке, и поэтому они, вероятно, привлекут внимание.

Answer 1

Это должна быть вики сообщества, так как она довольно субъективна и «правильного» ответа нет.

Тем не менее, вы должны развиваться на самой быстрой машине, доступной вам. Да, все, что медленнее, вызовет раздражение и побудит вас исправить замедления, но только по очень высокой цене:

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

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

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

Answer 2

Медленные компьютеры не помогут вам найти проблемы с производительностью.

Если ваши тестовые данные находятся всего в нескольких сотнях строк в таблице, ваша БД будет кэшировать все это, и вы никогда не найдете плохо написанных запросов или неверного дизайна таблиц / индексов. Если ваше серверное приложение не является многопоточным, вы не узнаете об этом, пока не проведете стресс-тестирование с 500 пользователями. Или если у приложения узкие места в пропускной способности.

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

Если производительность действительно критична («миллисекундные транзакции» в реальном времени), то вам необходимо разработать и внедрить набор тестов и инструментов, чтобы с научной точки зрения доказать себе, что ваши изменения делают это быстрее. Существует слишком много переменных, которые влияют на производительность.

Плюс есть классическое оправдание программиста, которое они будут приводить - «но оно работает медленно, потому что мы специально выбрали медленные компьютеры, оно будет работать намного быстрее, когда мы развернем его».

Если ваш коллега считает это важным, дайте ему медленный компьютер и возложите на него ответственность за «производительность»: -)

Answer 3

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

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

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

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

Answer 4

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

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

Любые различия в средах разработки и развертывания могут стать источником неожиданных проблем.

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

Зачем калечить ваших программистов только потому, что вы боитесь упустить потенциальную проблему? Это не вменяемая стратегия развития.

Paul.

Answer 5

Оптимизации следует избегать, разве это не дает нам Vista? : Р

Но, если серьезно, это всегда вопрос компромиссов. Важные вопросы, которые следует задать себе

Какую платформу будут использовать ваши конечные пользователи? Могу ли я сбросить циклы? Что будет, если я сделаю?

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

Answer 6

ради любви к Кодду, используйте инструменты профилирования, а не медленные машины разработки!

Answer 7

Я думаю, что это разумная концепция (но, может быть, потому, что она работает для меня).

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

Целевая машина вполне может содержать дросселированный процессор. Если - на встроенном MCU - у вас половина FLASH, RAM и тактовых циклов в секунду, то есть шансы, что разработчики будут намного осторожнее при разработке своего кода. Однажды я предложил байтовые переменные для длин отдельных записей в области данных (не в ОЗУ, а в последовательном EEPROM) и получил ответ «нам не нужно скупиться». Через несколько месяцев они достигли потолка оперативной памяти (128 КБ). Я подумал, что для этого приложения никогда не будет записей размером более 256 байт просто потому, что не было ОЗУ для их копирования.

Для серверных приложений, я думаю, было бы неплохо иметь (намного) менее производительное оборудование для тестирования. Два или четыре ядра вместо шестнадцати (или более). 1,6 ГГц istdo 2.8. Список можно продолжить. Сервер обычно - из-за самого факта, что все говорят с ним - узкое место в архитектуре системы. И это задолго до того, как вы начнете разрабатывать (серверное) приложение для него.

Answer 8

Обычно я развиваюсь на самой быстрой машине, которую могу достать.

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

Answer 9

Зависит от вашего времени доставки. Если вы находитесь в 12-месячном цикле поставки, то вам следует разработать коробку с приличной скоростью, так как через 12 месяцев ваши клиенты будут иметь «средние» коробки лучше, чем текущее «среднее».

Поскольку ваш цикл разработки приближается к «сегодняшнему», ваши машины разработки должны приближаться к текущей «средней» скорости коробок ваших клиентов.