Для «того стоит» нужен контекст, например, насколько проще писать, читать и поддерживать, а также то, насколько быстрее это делает что-то для пользователя заметно более отзывчивым, интерактивным, требующим меньше времени для ожидания.
Сохранение нескольких копеек для покупки банки с газировкой не принесет мне большой пользы, если мне придется преодолеть расстояние, чтобы спасти эти пенни, особенно с учетом того, что в эти дни я редко пью соду. Экономия нескольких копеек на банку при покупке миллиона банок газированных напитков может оказаться огромной проблемой.
Между тем я экономлю несколько копеек, когда рядом со мной находятся два человека, и один предлагает ту же самую вещь за несколько копеек дешевле, а другой нет, и я выбираю более дорогой, потому что мне нравится, что их шляпа лучше, кажется глупым делом пессимизации.
То, что я часто нахожу людьми, называющими «микрооптимизации», кажется странным образом лишенным измерений, контекста и обсуждения на уровне пользователя, когда должно быть абсолютно все три, чтобы рассмотреть такие оптимизации, если их нетривиально применять. Для меня правильная микрооптимизация в наши дни связана с такими вещами, как макеты памяти и шаблоны доступа, и хотя они могут показаться «микро» в фокусе, они не являются микро-эффектами.
Не так давно мне удалось сократить время работы с 24 секунд до 25 миллисекунд (примерно в 960 раз быстрее), с одинаковыми выходами (защищенными автоматизированными тестами), без изменений в алгоритмической сложности, для объемного рассеяния тепла, посредством «микрооптимизации» (самая большая из которых произошла из-за изменения в структуре памяти, которое сократилось примерно до 2 секунд, затем остальными были такие вещи, как SIMD и дальнейший анализ ошибок кеша в VTune и некоторая дальнейшая перестройка структуры памяти).
Вольфир объясняет здесь технику, и он боролся со временем, необходимым:
http://blog.wolfire.com/2009/11/volumetric-heat-diffusion-skinning/
Моей реализации удалось сделать это за миллисекунды, пока он изо всех сил пытался сократить это до менее чем минуты:
После того, как я «микрооптимизировал» его с 24 секунд до 25 мс, это стало поворотным моментом в рабочем процессе. Теперь художники могут менять свои установки в режиме реального времени со скоростью более 30 кадров в секунду, не дожидаясь 24 секунд каждый раз, когда они вносят небольшие изменения в свою установку. И это на самом деле изменило весь дизайн моего программного обеспечения, так как мне больше не нужны индикатор выполнения и все в этом роде, просто все стало интерактивным. Так что это может быть «микрооптимизация» в том смысле, что все улучшения произошли без какого-либо улучшения алгоритмической сложности, но это была скорее «мегаоптимизация», которая сделала то, что раньше было болезненным, неинтерактивным процессом в режиме реального времени, интерактивный, который полностью изменил способ работы пользователей.
Измерение, пользовательские требования, контекст
Мне очень понравился комментарий Роберта, и, возможно, я не смог сделать то, что хотел:
Ну, давай. Никто не собирается утверждать, что такого рода изменения не "стоят того". Вы смогли продемонстрировать ощутимую выгоду; многие так называемые микрооптимизации не могут.
Это, несмотря на то, что я работаю в очень критичной для производительности области, часто с требованиями в реальном времени, единственный раз, когда я рассматриваю любую микрооптимизацию, которая требует выхода из моего пути.
И я бы выделил не только измерения, но и пользовательскую сторону. Я странный в том, что я пришел в свою текущую область (и ранее gamedev) как пользователь / поклонник сначала, потом разработчик. Так что меня никогда не волновали обычные вещи, которые так волнуют программистов, как решение технических головоломок; Я нашел их бременем, но перенес бы их через мечту конечного пользователя, которой я поделился с другими пользователями. Но это помогло мне убедиться, что если я что-то оптимизирую, это окажет реальное влияние на пользователей с реальными преимуществами. Это моя защита от бесцельной микрооптимизации.
Это на самом деле так же важно, как и профилировщик, на мой взгляд, потому что у меня были коллеги, которые делали такие вещи, как микрооптимизация, деление куба на миллиард граней только для того, чтобы задушить реальные производственные модели, такие как персонажи и транспортные средства. Их результат был впечатляющим в некотором смысле «технической демонстрации», но почти бесполезным для реальных пользователей, потому что они профилировали, измеряли и тестировали примеры, которые не соответствовали реальным сценариям использования. Поэтому очень важно сначала понять, что важно для пользователей, либо научившись думать и использовать программное обеспечение как единое целое, либо сотрудничать с ними (в идеале оба, но, по крайней мере, сотрудничать с ними).