Вообще говоря, к какому типу оптимизаций вы обычно склоняетесь при разработке программного обеспечения?

Вы тот тип, который предпочитает оптимизировать свой дизайн для

• Время разработки (т. Е. Быстро писать и / или легче поддерживать)?
• Время обработки
• Место для хранения (RAM, DB, Disc и т. Д.)

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

техническое обслуживание

Затем профилируйте при необходимости и оптимизируйте по скорости. Редко когда-либо у меня была потребность в хранении - по крайней мере, за последние 10 лет. До этого я это делал.

Время разработки

Обработка и хранение дешево. Ваше время не

Просто отметить:

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

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

Пользовательский опыт.

Это единственная ценность, которая имеет значение для вашего клиента.

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

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

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

Эстетика менее важна. Я могу нарисовать Мона Лизу, но если она спрятана за стеной, никто не увидит ее.

Пользовательский опыт - единственная ценность, которая имеет значение. Создание приложения, которое делает именно то, что пользователь хочет так, как он ожидает, является конечным достижением.

Есть только одна вещь для оптимизации:

Что хотят ваши клиенты

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

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

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

Работаете на невероятно крошечном устройстве с ограниченными ресурсами? Оптимизируйте для этих ресурсов.

время обработки

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

Я склонен склоняться к ограничению потребления памяти и распределения. Я знаю, что это старая школа, но:

• Большая часть одноразового кода, который я пишу, сильно параллельна. Это означает, что чрезмерное выделение памяти и сбор мусора приведут к сериализации большого количества параллелизуемого кода. Это также означает, что будет большая конкуренция за шину общей памяти.
• Мой основной язык - D, который пока не имеет хорошей 64-битной поддержки (хотя это исправляется).
• Я работаю с довольно большими наборами данных на регулярной основе.

Я бы сказал, что оптимизируюсь в сторону эффективности, а эффективность определяется как компромисс между временем разработки, будущим обслуживаемостью, пользовательским опытом и потребляемыми ресурсами. Как разработчик, вы должны манипулировать всем этим, чтобы поддерживать какой-то баланс.

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

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

Какой бы технологией виртуализации я ни пользовался

Помните времена, когда системы с более чем 512 МБ ОЗУ считались самым передовым? Я провожу свои дни за написанием кода для предыдущего.

Я работаю в основном над программами низкого уровня, которые выполняются в привилегированном домене в среде Xen. Наш предел для привилегированного домена составляет 512 МБ, оставляя оставшуюся часть ОЗУ свободной для использования нашими клиентами. Для нас также характерно ограничение привилегированного домена только одним ядром процессора.

Итак, я пишу код, который будет работать на новом сервере стоимостью 6 тыс. Долл., И каждая программа должна работать (в идеале) в пределах выделенного потолка в 100 Кб или полностью отказаться от динамического выделения памяти.

Вкратце, я оптимизирую для:

• След памяти
• Сортировки (где большая часть моего кода тратит большую часть своего времени)

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

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

Это характерно и для тех, кто работает на встроенных платформах, хотя даже многие из них имеют в своем распоряжении как минимум 1 ГБ. Как отмечает Джейсон, это также типично при написании программ для запуска на мобильных устройствах. Список можно продолжить, киоски, тонкие клиенты, рамки для фотографий и т.д ..

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

Результаты исследований

Как академик, я решил поделиться тем, что оптимизирую. Обратите внимание, что это не то же самое, что оптимизация для более короткого времени разработки. Часто это означает, что работа может поддержать какой-то исследовательский вопрос, но не быть готовым, отшлифованным продуктом. Это может рассматриваться как проблема с качеством, и это может объяснить, почему многие говорят, что (академические) компьютерные ученые не имеют никакого опыта "реального мира". (Например, «Разве они не знали бы, как иначе разработать продукт?» )

Это тонкая грань. С точки зрения воздействия, вы хотите, чтобы ваша работа использовалась и цитировалась другими, и вступает в силу эффект Айсберга Джоэла : немного блеска и блеска может иметь большое значение. Но если вы не закладываете основы для других проектов, вы просто не сможете оправдать время, затрачиваемое на создание поставляемого продукта.

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

... после этого все остальное

... наконец, оптимизировать для производительности ;-)

Качество / Тестирование

Оптимизация в сторону качества, поскольку в графике разработки есть время для тестирования, как модульного тестирования, так и тестирования после функций / этапов.

Это зависит от необходимости вашей программы.

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

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

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

Elegance .

Если ваш код хорошо разработан, он будет иметь несколько эффектов:

1. Это будет легче поддерживать (сокращение расходов для клиента)
2. Будет проще оптимизировать (для JIT или полных компиляторов)
3. Это будет легче заменить (когда вы думаете о лучшем решении)

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

Поскольку я выполняю установку на нескольких типах систем - от мэйнфреймов IBM до ПК, я сначала оптимизирую на совместимость, затем размер, а затем скорость.

По-разному

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

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

Выразительность моего намерения.

Я хочу, чтобы кто-то, читающий мой код, мог легко видеть, какие операции я пытался вызвать в домене. Точно так же я стараюсь свести к минимуму несемантическое барахло (скобки, ключевые слова 'function' в js и т. Д.), Чтобы сделать сканирование проще

Конечно, вы должны сбалансировать это с ремонтопригодностью. Я люблю писать функции, которые возвращают функции и всевозможные продвинутые методы, и они ДЕЙСТВИТЕЛЬНО продвигают мою цель, но если выгода невелика, я ошибусь, если буду придерживаться техник, с которыми знакомы опытные программисты-младшие.

Все они

Время обработки

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

Место хранения

У вашего клиента может быть большой диск, скажем, 1Tb. Что может быть использовано 1000 HD фильмами, если вы хотите сделать его услугой, этого далеко не достаточно, не так ли?

Время разработки

Ну, я не уверен, что это считается «оптимизацией», что я делаю, я использую Java вместо C ++, и разработка идет в 10 раз быстрее. Я чувствую, что говорю прямо на компьютере, очень прямо вперед и полностью качается!

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