Ирина Козлова - Программирование

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

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

Оптимизация программы для уменьшения размера не похожа на оптимизацию для повышения быстродействия.

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

Во-вторых, проанализируйте программу.

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

Оптимизация кодов для любого языка всегда заставляет идти на компромиссы. Такими компромиссами являются:

1) сокращение используемого объема памяти в результате снижения быстродействия;

2) увеличение быстродействия в результате ухудшения возможностей сопровождения и доступности текста программы для чтения;

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

следующая требует больше времени, чем предшествующая. Рассмотрим эти операции: регистр/регистр, операции с памятью, операции с диском и операции взаимодействия с пользователем. Так что не стоит тратить силы на сокращение нескольких машинных циклов в программе, когда скорость ее исполнения ограничена операциями обращения к дисковым файлам. Взамен можно применить сокращение числа таких операций. А после выполнения того, что, в принципе, могло бы быть оптимизацией, следует осуществить тщательную проверку полученных результатов.

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

Если программа удовлетворяет всем приведенным критериям, то на самом деле ее объем и скорость выполнения чаще всего будут вполне приемлемыми без каких-либо дальнейших усовершенствований. Но только применение ассемблера само по себе приводит к повышению скорости выполнения программы в 2–3 раза и примерно к такому же уменьшению размера по сравнению с такой же программой на языке высокого уровня. Кроме того, если что-то делает проще чтение программы и ее сопровождение, то обычно при этом увеличивается скорость исполнения. Можно отказаться от «макаронных» кодов со многими ненужными переходами и вызовами подпрограмм, а также предпочтение простых прямолинейных машинных команд похожим сложным.

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