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

Question

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

Randall Hyde указывает на The Fallacy of Premature Optimization, есть много неправильных представлений вокруг Хоара цитаты:

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

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

Answer 8

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

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

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

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

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

Paul.

Answer 9

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

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

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

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