КПД (Коэффициент полезного действия) — это отношение полезной работы к затраченной энергии. КПД является безразмерной величиной и часто измеряется в процентах.
В принципе, в программировании тоже можно определить КПД. Как с точки зрения энергетической, так и с точки зрения алгоритмической. Процессор работает, потребляет энергию. Доля энергии, затрачиваемой на программу вполне легко определяется. Для простоты оценки можно считать количество тактов процессора, затрачиваемых на выполнение программы. Что касается полезной работы, это сложнее, но оценка тоже возможна. Для оценки порядка величины можно взять теоретическое минимальное количество инструкций, необходимое для выполнения программы. Допустим, наша задача - повернуть изображение, записанное в формате jpeg. Значит его надо декодировать, повернуть битмап, закодировать обратно. Для каждого шага известна оценка количества операций. Количество тактов даст полезную работу. В реальной программе операций будет больше, что и даст КПД, меньшее 100%.
В около-программной науке (не путать с около-научным программированием) чаще считают другие параметры. Раньше, когда стояли в очередь "на счёт", больше беспокоились процентами загрузки процессора. Потом стали считать транзакции в секунду, мегабайты throughput и миллисекунды latency. Не отрицая этих важных параметров, КПД мне нравится тем, что является некоторым показателем эффективности, а следовательно и качества общей архитектуры программы.
Иногда возможны трюки, которые поднимают КПД на порядки, заставляя пересмотреть теоретический минимум. Например в вышеприведённом примере, поворот на 90 и 180% можно сделать очень быстро, без раскодировки и интерполяции, переставив данные непосредственно в сжатом jpeg-файле.
Чаще, однако встречаются примеры, когда КПД на много порядков ниже, чем нужно. Что интересно, это может никого и не беспокоить. Работает и ладно. Всё равно, процессор не может стоять и будет крутить idle loop. Но, в принципе, idle loop лучше. В этом режиме он экономит батарею ноутбука, позволяет крутиться другим задачам на сервере, а процессор телефона переходит в мало-потребляющий режим. Кроме того, программы с большим КПД просто лучше продуманы. Такое КПД - качество дизана программы.
В качестве примера приведу Exchange со списками рассылки. Оказывается, что в современном Exchange нет single-instance-storage. Посланное сообщение и все его приложенные файлы просто копируются в inbox каждого реципиента. Это уменьшает зависимость данных, позволяет разделить inbox-ы по разным серверам и всё такое. Казалось бы, всё логично.
Смотрю на свой корпоративный inbox средних размеров. В нём несколько тысяч сообщений. Во всех - несколько реципиентов. Большая часть получена по ссылкам рассылки, где в каждой группе - сотни и тысячи человек. Каждое такое сообщение копируется в тысячу inbox-ов. Ответ на него тоже так же копируется, причём, традиционно, текст включает сам вопрос и предыдущее обсуждение. И всё это в сложных кодировках, в HTML, который упакован в MIME, который пересылается в XML, через HTTPS, используя .NET Web-сервисы.
Простое и типичное форумное сообщение "+1", которое с точки зрения полезной работы, "как два байта переслать", превращается в гигабайты дисковой памяти и дальше, в соотвествующий сетевой трафик и фантастические компьютерные стойки, которые непрерывно что-то друг с другом синхронизируют, а затем всё это ещё и с моим компьютером.
Но и это ещё не всё. Обычно каждый пользователь настраивает правила так, чтобы списки рассылки попадали в свои отдельные папки. А затем новый Outlook в Conversation View сжимает всё обсуждение до своего логического минимума, показывая в нём ту самую единственную строчку: "+1".
Даже затрудняюсь оценить, какой у этого дизайна КПД. Какие-то бесконечно малые числа. Удивительно, что это вообще может работать на современной технике. Но как я могу осуждать архитекторов за это, если пси функция движущейся частицы тоже расширяется на всю вселенную, чтобы потом свернуться в нужную точку? Почти как в Exchange.