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

• Передача параметров по значению там, где применима передача параметров по ссылке (рекомендация 25).

• Использование постфиксной версии ++ там, где с тем же успехом можно воспользоваться префиксной версией (рекомендация 28).

• Использование присваивания в конструкторах вместо списка инициализации (рекомендация 48).

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

Два важных способа усовершенствования программы, которые делают ее одновременно и яснее, и эффективнее — это использование абстракций (см. рекомендации 11 и 36) и библиотек (рекомендация 84). Например, использование vector, list, map, find, sort и других возможностей стандартной библиотеки, стандартизированных и реализованных экспертами мирового класса, не только делают ваш код яснее и легче понимаемым, но зачастую и более быстрым.

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

Ссылки

[Keffer95] pp. 12-13 • [Stroustrup00] §6 introduction • [Sutter00] §6

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

Резюме

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

Обсуждение

Это утверждение носит более общий характер, чем более узкое требование рекомендации 18.

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

Имена объектов в глобальном пространстве имен приводят к его дополнительному засорению.

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

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

Предпочтительно обеспечить низкую связность и минимизировать взаимодействие классов (см. [Cargill92]).

Исключения

Такие средства уровня программы, как cin, cout и cerr, являются специализированными и реализуются специальным образом. Фабрика должна поддерживать реестр функций, которые должны вызываться для создания данного типа, и такой реестр обычно один на всю программу (тем не менее предпочтительно, чтобы он был внутренним объектом по отношению к фабрике, а не глобальным совместно используемым объектом; см. рекомендацию 11).

Код, в котором объект совместно используется разными потоками, должен обеспечить сериализацию обращений к такому объекту (см. рекомендацию 12 и [Sutter04c]).

Ссылки