Публикую недописанное чтобы не потерять и не забыть. Надеюсь домучать в ближайшее время.
Хочу показать основные известные мне капитанские "лайфхаки" которые позволяют достаточно быстро и эффективно сделать обычное "неидеальное и говнокодистое" приложение быстрее. Это попытка упорядочить и уточнить примерами и тестами последний год моей работы в геймдеве.
Хочу показать основные известные мне капитанские "лайфхаки" которые позволяют достаточно быстро и эффективно сделать обычное "неидеальное и говнокодистое" приложение быстрее. Это попытка упорядочить и уточнить примерами и тестами последний год моей работы в геймдеве.
Итак, предположим что у нас есть тормоза.
Начну с того что лазать по коду вслепую и менять в циклах i++ на i--, кешировать что ни попадя и тд крайне неэффективно. Особенно в свете того что часто оптимизация перфоманса ухудшает читаемость кода, что может привести к прямо противоположным результатам, маскируя своей сложностью несуразность происходящего.
Поиск проблем.
Начну с того что лазать по коду вслепую и менять в циклах i++ на i--, кешировать что ни попадя и тд крайне неэффективно. Особенно в свете того что часто оптимизация перфоманса ухудшает читаемость кода, что может привести к прямо противоположным результатам, маскируя своей сложностью несуразность происходящего.
Поиск проблем.
Для определения тяжелых мест можно использовать замечательный скаут (профайлер). Работа со скаутом остается за кадром, так как методом тыка все быстро осваивается. Замечу только, что для превращения обычных swf в swf с телеметрией я использую SWF Scout Enabler (есть другие, более правильные способы, но имхо это самый простой).
Стоит обратить внимание на две вещи - массовые выделениях памяти и кадры что заняли много времени. В них и смотреть, вплоть до самого жесткого и малочитаемого переписывания.
Рефакторинг.
Первое что я делаю с тяжелым кодом это улучшение читаемости (и не забываем на случай неприятностей делать это отдельным коммитом!).
Переименовыаю невнятные локальные сущности, добавляем комментарии.
Для дальнейший работы требуется ясно читаемый алгоритм и намерения автора по использованию кода, иначе вероятность привнесения бага оптимизацией будет стремиться к 100%.
Важно на этом этапе ничего не менять в логике, опять же вероятность внесения багов очень велика. Большие дяди советуют делать юнит тесты, но в грустном моем мире делать их до того как поймешь как работает код бессмысленно, а после уже не особо и нужно (тут работает принцип распределения времени на самые горящие задачи, работать дальше со стабильным кодом обычно возможности нету).
Снижение количества вызовов блоков кода.
Часто вызываемый код как правило основной источник проблем. Самый простой и эффективный способ снизить нагрузку - внимательно посмотреть на него и оценить необходимость вызова.
Например MOUSE_MOVE как событие вызывающее тяжелый код вот прямо сразу идет лесом, так как вызывается слишком часто.
Ускорение доступа к данным, индексация.
//TODO
Кеширование.
//TODO
Пуллинг.
//TODO
Стоит обратить внимание на две вещи - массовые выделениях памяти и кадры что заняли много времени. В них и смотреть, вплоть до самого жесткого и малочитаемого переписывания.
Рефакторинг.
Первое что я делаю с тяжелым кодом это улучшение читаемости (и не забываем на случай неприятностей делать это отдельным коммитом!).
Переименовыаю невнятные локальные сущности, добавляем комментарии.
Для дальнейший работы требуется ясно читаемый алгоритм и намерения автора по использованию кода, иначе вероятность привнесения бага оптимизацией будет стремиться к 100%.
Важно на этом этапе ничего не менять в логике, опять же вероятность внесения багов очень велика. Большие дяди советуют делать юнит тесты, но в грустном моем мире делать их до того как поймешь как работает код бессмысленно, а после уже не особо и нужно (тут работает принцип распределения времени на самые горящие задачи, работать дальше со стабильным кодом обычно возможности нету).
Снижение количества вызовов блоков кода.
Часто вызываемый код как правило основной источник проблем. Самый простой и эффективный способ снизить нагрузку - внимательно посмотреть на него и оценить необходимость вызова.
Например MOUSE_MOVE как событие вызывающее тяжелый код вот прямо сразу идет лесом, так как вызывается слишком часто.
Ускорение доступа к данным, индексация.
//TODO
Кеширование.
//TODO
Пуллинг.
//TODO
Распределение нагрузки.
Когда код более менее вычищен а тормозов есть стоит обратить внимание на пики нагрузки еще раз. Чтобы юзер не видел залипаний можно уводить расчеты в поток, отслеживать загруженность системы и не запускать тяжелые методы вроде ручного gc в моменты когда фпс ниже нормы. Если цп уйдет в 100% быстрее не будет, поверьте, будет медленнее (не считая нервов юзера у которого все залипло, и не забываем про 15 секунд лимита после которых плеер просто прибьется).
Простейшая реализация тут - github.com/.../SimpleCallManager.as, использование - github.com/.../ThreadSimpleMain.as.
И теперь уже можно сюда.
gskinner.com/talks/quick
help.adobe.com/ru_RU/as3/mobile/flashplatform_optimizing_content.pdf
jacksondunstan.com
Всем добра.
Когда код более менее вычищен а тормозов есть стоит обратить внимание на пики нагрузки еще раз. Чтобы юзер не видел залипаний можно уводить расчеты в поток, отслеживать загруженность системы и не запускать тяжелые методы вроде ручного gc в моменты когда фпс ниже нормы. Если цп уйдет в 100% быстрее не будет, поверьте, будет медленнее (не считая нервов юзера у которого все залипло, и не забываем про 15 секунд лимита после которых плеер просто прибьется).
Простейшая реализация тут - github.com/.../SimpleCallManager.as, использование - github.com/.../ThreadSimpleMain.as.
И теперь уже можно сюда.
gskinner.com/talks/quick
help.adobe.com/ru_RU/as3/mobile/flashplatform_optimizing_content.pdf
jacksondunstan.com
Всем добра.
