Когда / как оптимизировать общий код?

Question

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

Answer 1

"Как производительность должна быть сбалансирована с другими целями дизайна ...?"

1. Получите его на работу.

2. Оптимизируйте его, пока он не сможет быть оптимизирован.

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

Оптимизация все еще очень, очень важна. Преждевременная оптимизация не означает НЕТ оптимизации. Это значит оптимизировать после того, как все заработает.

Answer 2

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

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

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

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

Answer 3

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

Всем известна известная цитата: Преждевременная оптимизация - корень всего зла. .
Однако это только половина. Полная цитата:

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

Посмотрите на это внимательно - скажем, в 97% случаев .
Другая сторона этого утверждения - примерно в 3% случаев, "малые" эффективности имеют решающее значение .

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

ИМХО, вы всегда должны думать о производительности. Вам не следует тратить на это много усилий или жертвовать ремонтопригодностью до тех пор, пока это не будет доказано профилированием / тестированием, но вы обязательно должны иметь это в виду.

Я бы лично применил это к универсальному коду:
У вас обязательно есть где-то код, который, когда вы его писали, вы думали «это будет медленно» или «это глупый алгоритм, но он сейчас не важен, поэтому я исправлю его позже». Поскольку вы находитесь в разделяемой библиотеке и не можете утверждать, что метод A будет вызываться только с 5 элементами, вы должны пойти и почистить все это.

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

Answer 4

Мое эмпирическое правило:

не оптимизировать

Полное правило на самом деле:

если у вас нет метрики, не оптимизируйте

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

В конце концов: без метрики, как вы знаете, что оптимизировать?

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

Answer 5

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

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

Answer 6

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

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

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