Если вы работаете в действительно критичных для производительности областях, то вы не можете откладывать эффективность в качестве запоздалой мысли. Это одна из самых важных вещей, о которой следует подумать при раннем проектировании в тех случаях и способами, которые связаны с ремонтопригодностью конечного результата.
Вы не можете спроектировать и внедрить крупномасштабный сервер и просто начать писать простой, хорошо документированный код, который просто использует функции блокировки для всего с глобальной блокировкой потоков, которая блокирует всю систему для обработки каждого отдельного клиентского запроса, не помещая никаких мысли вообще в общее состояние, спор нити и асинхронность. Таков рецепт катастрофы и необходимость переделывать и переписывать основную часть хорошо документированного кода, который вы написали таким образом, который может привести к созданию наиболее сложной в обслуживании кодовой базы, которую можно себе представить, из-за гонок и тупиков в результате попыток чтобы достичь требуемой эффективности в ретроспективе, а не просто подумать об эффективных, простых, работающих проектах заранее.
Команда разработчиков игр уже 8 месяцев работает с двигателем, который работает на скорости 2 кадра в секунду на самом мощном оборудовании с 32 ядрами, и имеет тенденцию останавливаться на 15 секунд каждый раз, когда экран загружается, вряд ли сразу получит продукт, который можно использовать, просто исправление одной маленькой локализованной точки доступа. Скорее всего, их дизайн FUBAR таким образом, что гарантирует эпическое пересмотр чертежной доски и изменения дизайна, которые могут каскадно войти в каждый угол кодовой базы.
С Джоном Кармаком он однажды рассказал о том, как техническая демонстрация должна работать с минимальной скоростью от сотен до тысяч кадров в секунду, чтобы интегрировать ее в производство. Это не нездоровая одержимость эффективностью. Он заранее знает, что игры должны запускаться со скоростью более 30 FPS, чтобы покупатели находили это приемлемым. В результате один маленький аспект, такой как система мягких теней, не может работать со скоростью 30 FPS, иначе игра в целом не может быть достаточно быстрой, чтобы обеспечить необходимую обратную связь в реальном времени. Это непригоден до тех пор, пока не достигнет необходимой эффективности. В таких критически важных для производительности областях, где существует фундаментальное требование к эффективности, решение, которое не может достичь достаточной скорости, на самом деле не лучше, чем решение, которое вообще не работает, поскольку оба полностью, И вы не можете спроектировать эффективную систему мягких теней, которая будет работать с сотнями и тысячами кадров в секунду, как это требуется для игрового движка реального времени, если вы не будете заранее думать о ее эффективности. На самом деле, в таких случаях 90 +% работы ориентированы на эффективность, поскольку тривиально создать систему с мягкими тенями, которая прекрасно работает при 2 часах на кадр, используя трассировку пути, но вы не можете ожидать ее настройки. чтобы работать с сотнями кадров в секунду без совершенно другого изменения подхода.
Когда эффективность является фундаментальной частью дизайна приложения, вы не можете ожидать, что вы достигнете эффективности в ретроспективе, не теряя значительно больше времени, чем сэкономили, игнорируя его, поскольку вы не можете ожидать, что получите работающий дизайн в ретроспективе. Никто не говорит: « Можно отложить мысль о дизайне на потом. Просто хорошо документируйте свой код, и вы сможете придумать правильный дизайн позже». ». Но в архитектурах, критически важных для производительности, это то, что вы делаете эффективно, если вы не уделяете много внимания и заранее продумываете эффективные проекты.
Теперь это не значит, что вам нужно сразу же настраивать свои реализации. Что касается деталей реализации, то есть много возможностей перейти к более быстрым решениям после измерения при условии, что дизайн не нужно будет менять, и часто это наиболее продуктивный способ решения этой задачи. Но на уровне дизайна это означает, что вы должны задуматься о том, как дизайн и архитектура будут с самого начала относиться к эффективности.
Ключевое отличие здесь дизайн, Оглядываясь назад, нелегко вносить большие изменения в проекты, так как проекты накапливают зависимости, и зависимости изменяются при изменении дизайна. И если дизайн требует разумной эффективности или, в некоторых случаях, что его качество в значительной степени измеряется его эффективностью, то не стоит ожидать, что вы сможете добиться правильного дизайна в качестве запоздалой мысли. С любой конкурирующей продукцией, где эффективность является огромным аспектом качества, будь то операционные системы или компиляторы, видеопроцессоры, raytracers, игровые движки или физические движки, мысли об эффективности и представлении данных тщательно продумывались с самого начала. И в этих случаях это не преждевременная оптимизация, чтобы заранее задуматься об эффективности. Именно такая мысль была поставлена в самое продуктивное время,