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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

Пол.

Answer 5

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

Целевая машина вполне может содержать управляемый процессор.Если - на встроенном MCU - у вас вдвое меньше ФЛЭШ-памяти, оперативной памяти и тактовых циклов в секунду, скорее всего, разработчики будут намного осторожнее при разработке своего кода.Однажды я предложил использовать байтовые переменные для длины отдельных записей в области данных (не в оперативной памяти, а в последовательной eeprom) и получил ответ "нам не нужно скупиться". Несколько месяцев спустя они достигли потолка оперативной памяти (128 КБ).Я размышлял о том, что для этого приложения никогда не будет записей размером более 256 байт просто потому, что не было оперативной памяти для их копирования.

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

Answer 9

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

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