В группе операционных систем, мы должны принять целостный взгляд на производительность. Цель состоит в том, чтобы заставить всю систему работать быстрее, балансируя приложения между друг другом для общего блага.
Приложения, с другой стороны, как правило, имеют эгоистичную точку зрения на производительность: "Я сделаю всё возможное, чтобы заставить себя работать быстрее. Влияние на остальную часть системы - не моя забота".
Некоторые приложения заносят себя в папку Автозагрузка, так что они смогут запуститься быстрее. На самом деле, это не делает систему быстрее; просто смещает приоритеты. Откусывая от стоимости запуска приложения и приплетая это время к запуску ОС, время от запуска приложения пользователем до готового приложения действительно уменьшается. Но общее время остаётся неизменным.
Например, рассмотрим следующую диаграмму. "*" отмечает момент включения машины, "+" означает время, когда пользователь щёлкнул по ярлычку программы, а "!" указывает на точку, когда приложение полностью готово.
| * | Запуск ОС | + | Запуск приложения | ! |
| * | Запуск ОС | + | Запуск приложения 1 | Запуск приложения 2 | ! |
| * | Запуск ОС | Запуск приложения 1 | + | Запуск приложения 2 | ! |
Потом команда разработчиков указывает это, более короткое, значение в своих отчётах производительности и, может быть, они устраивают ужин, чтобы это отпраздновать.
Конечно же, если вы взглянете на картину целиком, от звёздочки до восклицательного знака, то увидите, что ничего не изменилось. Время полной готовности вашего приложения с холодного старта не изменилось. Всё, что это "улучшение производительности" сделало - rob Peter to pay Paul. Время проводимое в "Запуске приложения 1" теперь снимается с запуска всей системы, а не с приложения. Вы переставили местами числа, но пользователь ничего не выиграл.
Фактически, пользователь даже что-то потерял. В диаграммах выше мы предполагали, что пользователь хочет запустить вашу программу! Но если он не хочет этого делать, а просто хочет проверить свою почту, то он всё равно будет платить за "Запуск приложения 1", даже хотя он не собирается запускать вас.
Другой пример приложения с эгоистичным взглядом на производительность пришёл от компании, которая разрабатывала обработчик оверлея иконок. Оболочка рассматривает оверлеи иконок как низко-приоритетные вещи, поскольку гораздо более важным является вообще показать значок на экране, чтобы пользователь скорее начал делать то, что он там собирался делать. Декорации могут подождать. Так вот, эта компания хотела знать, как они могут улучшить свою производительность, чтобы показать свои оверлеи на экране ещё раньше, чем даже появятся сами значки, показывая этим своё феноменально эгоистичное представление "производительности".
Производительность - это сделать так, чтобы пользователь быстрее решал свои задачи. Если задача не включает в себя запуск/использование вашей программы, то ваше "улучшение производительности", на самом деле, является деградацией производительности. Нет, я уверен, что ваша программа прекрасна и полезна, но будет несколько самоуверенно полагать, что каждый пользователь, который установит её, будет считать её запуск самым важным делом в своей жизни.
При.пер.: упаковщики исполняемых файлов - ещё один пример не самой дальновидной "оптимизации".
>При.пер.: упаковщики исполняемых файлов - ещё один пример не самой дальновидной "оптимизации".
ОтветитьУдалитьА можете пояснить? Действительно интересно где в этом прокол.
На эту тему написано достаточно много.
ОтветитьУдалитьВот например.
Кратко суть: упаковка исполняемых файлов пришла из времён MS-DOS, когда она имела смысл. Все её преимущества теряются в Win32 (тем не менее, изредка бывают ситуации, когда упаковка полезна, но они - единичны; в большинстве случаев, упаковывая файлы вы делаете только хуже).
> rob Peter to pay Paul.
ОтветитьУдалитьВ русском языке есть эквивалент "тришкин кафтан". Правда, он известен только начитанным людям (нет, я не хочу вас обидеть :)
А насчет упаковки – она более-менее защищает от взлома, но это, пожалуй, и все.
Ну, мне кажется, что довольно удачный перевод будет "отдать долги, сделав новые".
ОтветитьУдалитьИнтересно, почему никому из разработчиков Adobe Reader'а (и прочей подобной шелухи, очень любящей пихать свои runner'ы в автозагрузку) не приходит в голову запускать это самый runner при первом запуске самого приложения, а не при старте системы?..
ОтветитьУдалить