Оптимизация аддонов

[OLDodin]

По моим наблюдениям

Все вызовы api работают довольно медленно, а некоторые оооочень медленно. Например, очень медленный object.GetBuffInfo(), у кого тормозят аддоны в БГ/Рейдах/Арена Смерти/РЧД может из-за избытка таких вызовов. А значит нам нужно минимизировать кол-во таких вызовов.

Приёмы для этого

1) Фильтры условий - перебираем/обрабатываем/храним не все, а лишь нужное в текущий момент

Например, я минимизирую кол-во вызовов object.GetBuffInfo(), те убираю чтение этого бафа со всех, кроме таргет/пет/я,  если нужны не все бафы, то фильтровать обработку только по нужным.

2) В ивентах только запоминать факт изменения чего либо, а обработку изменений производить  по таймеру - за промежуток вызова таймера может прийти несколько событий на 1 объект, а обработаем изменение всего 1 раз

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

4) Компиляция всех исходников может давать 10% ускорения. Для отладки это не удобно, но перед выкладкой аддона сделать это весьма неплохо.

Гайд по компиляции =),

а) Создаём папку "sources", переносим в неё .lua файлы

б) заходим в "Аллоды Онлайн\data\Mods\Docs\ModdingDocuments.zip\LuaCompiler\"

в) копируем содержимое папки в LuaCompiler в созданную папку (sources)

г) при необходимости в compile.bat меняем имя exe файла, или пути

д) запускаем compile.bat (он в аттаче, откомпилит все .lua файлы и результат поместит в родительской для sources  папке)

 

compile.bat

[OLDodin]

Еще несколько замеченных проблем

1) Довольно медленная работа common.CompareWStringEx  - будьте осторожны при проверках в циклах. Сотни таких сравнений и вылезут "часики". Если возможно использовать другие признаки для сравнений или изыскивать способы уменьшения числа их вызовов. Либо используйте common.CompareWString

2) Вызовы GUI - SetBackgroundTexture, Widget:Show, SetPlacementPlain, и прочие. Сотни таких вызовов за цикл обработки выбивают "часики".

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

Если не удается отказаться от перебора устанавливать значения GUI элемента после проверки. Сравнить текущее значение элемента с новым, текущее значение или получать у GUI элемента или хранить самому. Как ни странно, но это работает быстрее.

Например

if  aVisible ~= anWidget:IsVisible() then
   anWidget:Show(aVisible)
end

 

[OLDodin]

Сделал замер производительности строк в АО.

Поиск строки в массиве строк(40шт), 10к итераций (например, БГ 24 человека в сумме, по 50 бафов на каждом получим 1200 итераций, * на кол-во доп сравнений)
ЦП FX-6300 (3,8Ггц), ОЗУ 1600Мгц (11 тайминги, двуранг)

1) тип строк нативный string    =10мс
2) тип строк нативный string + avl tree    =8мс
3) строка1 нативный string, строка2 WString (конвертация FromWString в string для сравнения)    =50мс
4) тип строк WString (сравнение CompareWString)    =380мс
5) тип строк WString (сравнение CompareWString) + avl tree    =60мс
6) тип строк WString (сравнение CompareWStringEx)    =5000+мс

*При увеличении размера массива строк avl будет давать больший выигрыш
*Понятно что в моем тесте (простой цикл) не будет кэш промахов проца, в реальной ситуации тайминги будут повыше
*п1-2 просто для сравнения с нативными строками lua, большая часть строк из движка это WString

Вывод - конвертация WString в string для сравнения самый быстрый способ (при размере массива строк порядка 1-70). Но у него есть недостаток - могут быть проблемы с символами язывков отличных от английского и русского. Сравнимым по производительности будет CompareWString с использованием АВЛ дерева и без проблем с языками.

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

[Скобыч]

А в каком юз-кейзе нужно искать среди 10к строк? Если про бафы - то там лучше по resourceId поиск делать.

И про 10% от компиляции тоже не верится. После загрузки скрипта (что после компиляции, что до) в памяти хранится только байт-код. и он идентичен. На скорость выполнения никак не должно влиять.

[OLDodin]

4 часа назад, Скобыч сказал:

А в каком юз-кейзе нужно искать среди 10к строк? Если про бафы - то там лучше по resourceId поиск делать.

И про 10% от компиляции тоже не верится. После загрузки скрипта (что после компиляции, что до) в памяти хранится только байт-код. и он идентичен. На скорость выполнения никак не должно влиять.

1) resourceId тоже надо найти и он точно различен для, например бафов с одинаковой иконкой, но разным названиям?

2) Есть ли у вас данные по таймингам IsEqual для resourceId ?

3) 10к строк - очевидно что для получения различимых цифр. Например, и для 0,5к  19мс это овер*** так-то.

4) про 10% написал когда только начинал разбираться в Lua и судил по игровым показателям в окне аддонов. Если Ао при загрузке скрипта прогоняют его компиляцию (не просто в байт код, а именно luajit компилятором), то разницы не будет, а так некоторые оптимизации компилятор проводит.

[OLDodin]

Прогнал аналогичный тест для сранений по resourceId получил 160мс для аналогичного тестам выше объема сравнений.

Да быстрее строк, но хуже п3 и п5 из теста