Беседы о программировании

 

Разработчики приложений для ПК всегда были уверены в том, что системы будут все быстрее и быстрее.

 

Но дальше так не может продолжаться.

 

Несомненно, быстродействие процессора возрастает и, как результат, машины ждут быстрее, чем когда-либо прежде.

 

Во время оно эти быстрые ПК просто ожидали следующего нажатия клавиши пользователем, но теперь возможности выросли. Сегодня центральный процессор может точно так же ожидать реакции файл-сервера, модем-сервера, Web-сервера, сервера печати или шлюза электронной почты.

 

Друзья, а как быстро ждет Alpha с тактовой частотой 500 МГц!

 

Пользователи становятся подозрительными. В обзоре, выпущенном в середине августа корпорацией International Data, говорится, что три из пяти проектов систем (оценка по 220 проектам на предприятиях с более чем 500 сотрудниками) имели своей целью повысить производительность приложений. Замены ПК с процессором класса 486 и тактовой частотой 100 МГц на машины с 200 МГц процессором Pentium Pro уже недостаточно, чтобы обеспечить пользователям привычную кривую роста производительности.

 

Было бы нелепо отвечать ускорением не тех частей системы.

 

Если не система, а пользователь является "узким местом", снижающим производительность при выполнении заданий, мы должны так спроектировать систему, чтобы у пользователя возникало меньше вопросов по ходу работы.

 

В противном случае мы можем как угодно долго нагромождать многоуровневые решения, оптимизировать алгоритмы индексации, подбирать размер кэш-памяти, дорабатывать стратегии тиражирования и расширять полосу пропускания сети, причем бюджет невероятно распухнет. Но совсем не обязательно, что это поможет.

 

Что же заставляет пользователей тратить больше времени, чтобы завершить свои задания? Ожидание ответа системы? Как правило, нет.

 

Когда в исследовании 1983 года оценивали возможности пользователей на одной обычной задаче, то обнаружили, что самая большая часть непроизводительных затрат времени приходилась на исправление ошибок.

 

Так что прежде чем вы замерите время реакции, например на правильно сформулированный запрос, может быть, вам следовало бы сначала определить, какая часть пользовательских запросов рассматривается самим пользователем как успешная. Если обычно пользователь посылает два запроса для получения каждого полезного результата, я могу показать вам быстрый путь удвоения производительности вашей системы.

 

Подумайте об этом как об улучшении обработки в системе, прежде чем начать работу по уменьшению времени отклика. Эталонный тест начинается не тогда, когда пользователь задает правильный вопрос, и заканчивается, когда система возвращает правильный ответ. Эталонный тест начинается тогда, когда пользователь решит, что хочет что-либо узнать, и заканчивается тогда, когда он все выяснит.

 

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

 

Если один и тот же пункт выбирается более чем в 50% случаев, то использование многоуровневого меню  -  чистая экономия времени: меню первого уровня может состоять из наиболее часто выбираемой альтернативы и пункта "прочее". В компиляторах не существует такой оптимизации, которая бы делала это за вас  -  ни в Smalltalk, ни в Java.

 

Рост быстродействия микросхем больше не означает ускорения приложений. Если вы думаете, что уже делаете в этой области все, что можете, то, скорее всего, это не так  -  вы еще и не начинали.

 

Питер Коффи

 

Связаться с Питером Коффи можно по адресам: MCI Mail 357-1756, CompuServe 72631,113 или 3571756@mcimail.com.