Рефакторинг (и тестирование) для производительности

Question

У меня есть библиотека, которая предоставляет API отражения поверх описанияType() (метод, который возвращает объект XML со всеми спецификациями класса или экземпляра). Поскольку эта библиотека используется в нескольких других библиотеках и фреймворках, я действительно хочу, чтобы она была как можно быстрее.

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

Так что это приносит мне на следующие вопросы:

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

Answer 1

Вы можете использовать профилировщик от FlashBuilder (не бесплатно), чтобы узнать, где можно улучшить.

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

Если вы хотите увидеть, что происходит под капотом и понять больше скомпилированный код, посмотрите исходный код tamarin (использование Adobe VM в проигрывателе Flash) и изучите abc bytecode

Или напишите несколько функций и измерьте их производительность, шаг за шагом сделайте небольшой рефакторинг, чтобы узнать, что такое выигрыш, вы может использовать gskinner library для измерения (не используйте проигрыватель отладки, так как некоторые функции медленнее int).

Прочтите документ на as3 optimisation. Есть такие хорошие люди, как Joa Ebert, Grant Skinner.

Но если коэффициент усиления после оптимизации невелик, рекомендуется сохранять читаемость вашего кода.

Answer 2

Вы хотите получить profiler. У вашего компилятора должен быть один, например gprof поставляется с GCC - есть a tutorial here.

Answer 3

Измерение и заключение - это разные проблемы.

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

Какое измерение полезно для того, чтобы видеть, сколько времени было фактически сохранено.

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

Хороший профайлер RotateRight/Zoom. Я использую this technique.