Числа, приведенные в табл. 8.1, являются суммой пользовательского и системного времени процессора и вычислены с помощью функции

.

Программа	(3,3)	100*fib(1000)
hoc	5.5	5.0
bas	1.3	0.7
bc	39.7	14.9
c	<0.1	0.1

Таблица 8.1: Время работы на PDP-11/70 (в секундах)

Можно также приспособить Си программу для определения количества времени, используемого каждой функцией. Программу нужно перетранслировать в режиме профилирования, введя флаг

в каждой единице трансляции Си и при режиме загрузки. Если изменить файл для чтения:

чтобы команда

задействовала переменную , а затем задать

то результирующая программа будет выполняться с профилированием. После выполнения программы остается файл

, который интерпретируется программой профилировщиком .

Для иллюстрации изложенного мы протестировали

на приведенной выше программе Фибоначчи:

Запуск теста

Анализ

Результаты, полученные с помощью профилировщика, также подвержены случайным вариациям, как и те, что получены с помощью функции

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

Для проверки этого предположения мы изменили

, заменив вызовы и на макрокоманды, управляющие стеком:

(Функция

все-таки нужна в качестве кода операции нашей машины, поэтому нельзя заменить все обращения к ней.) Новая версия выполняется на 35% быстрее; время в табл. 8.1 сокращается от 5.5 до 3.7 с и от 5.0 до 3.1 с.

Упражнение 8.22

В макрокомандах

push

и

popm

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

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

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

и , а также , , и .