Что следует оптимизировать?

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

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

Выполнение оптимизации

Для оптимизации  счастье от комфортного пользования программами должно быть измеримыми. Вы не можете измерить счастье. Тем не менее, вы можете измерить время запуска, так что вы можете сказать, что вы улучшили его. Счастье будет тогда. Первое, что вы должны сделать, это найти способ изменить время, затраченное на выполнение задачи. Существует большая разница между программой, которая должна быть быстрой и программой, которая является быстрой. Если у Вас есть исходник программы, то вы можете протестировать ее, чтобы выяснить, почему ваш код не оптимизирован как следует. Очень заманчиво сделать это путем проведения осмотра: просто глядя на код и пытаться обнаружить то, что выглядит неправильно и нуждается в улучшении. Вы непременно ошибетесь. Используйте Profiler, чтобы получить подробный отчет  и быть уверенным, что ваша программа действительно является максимально оптимизированной.

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

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

·         Убедитесь, что Ваш код правильный и ошибки, освобождаются до оптимизации. Проверьте, что он остается правильным и ошибка, исчезает после оптимизации.

·         Оптимизация на высоком уровне является более приоритетной перед детальной оптимизацией.

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

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

·         Убедитесь, что вы выбрали широкий спектр материалов для оптимизации.

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

Низкоуровневые Подсказки

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

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

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

·         Не используйте код на ассемблере. Он не является портативным и, хотя он может быть быстрым на одном процессоре, он гарантировано не должен быть быстрым для каждого процессора и поддерживать его архитектуру (например, Athlon против Pentium 4).

·         Не переписывайте существующие стандартные библиотеки, если вы уверены, что это неоправданно медленно. Много CPU-интенсивных процедур библиотек уже оптимизированы. И наоборот, некоторые библиотеки подпрограмм медленны, особенно те, которые делают системные вызовы для операционной системы.

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

·         Сделайте вещи в холостом цикле. Это проще, чем при использовании программы Full Multi-Threading, но все еще получает вещи сделанные на глазах пользователей. Будьте осторожны, если вы тратите слишком много времени простоя в цикле, ваша программа станет вялой.

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

Продолжение следует...