Прикрепленные файлы

MSCV.rar (21.1 Кбайт, 109 просмотров )

Sergey ну да, здесь бы тебе пригодились хеш-функции. Забавно, а массивы безразмерные?

Прошу прощения, вновь произошла дезинформация :(.

Испытания с кешем были неточны, т.к. параллельно я опробывал запись параметров в строки и их расшифровку.

Если же поставить чистый кешь, то результат примерно одинакоый - что у массивов, что у кеша. Т.е. примерно при 100 движущихся объектах с периодом 0.05 начинается торможение. Никакой особой разницы не заметил на своем компе средней мощности:(. То ли что-то не так с алгоритмами...

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

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

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

в общем, вопрос, имхо, требует дополнительного исследования =)

Я реализовал на 1 карте 4 способа:
1) Кешь со строками (самый медленный, т.к. со строками war3 работает медленнее, чем с кешем)
2) Чистые массивы с перебором записей (гораздо быстрее, но медленнее остальных способов)
3) Чистый RS+кешь (средняя скорость)
4) RS, массивы и особый способ нахождения modulo (самый быстрый, но возмоджны баги с совпадением индексов + одному объекту можно сопоставить лишь 1 запись).

При этом, если создавать периодические триеггеры (период 0.05) для движения юнитов, торможения для методов 2-4 начинается на числе 80-90 единиц. Торможение в разной степени, но тем не менее, при любом методе гейплей становится неиграбельным.

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

Поскольку торможение в способах 2-4 начинается примерно с одного числа, вывод - торможение НЕ связано со способом получения и записи данных (массивы, кешь). Оно связано с торможением при выполнении внутренних команд war3 вроде вычисления синусов или команд вроде переместить юнит.

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

Предлагаю картостроителям провести эксперименты, какие триггерные действия вызывают торможение скрипта.

самое простое тестирование можно провести следующим методом...

запустить бесконечный цикл, увеличивающий переменную на 1, затем смотреть, на каком значении оно оборвалось =)

вот первые результаты:

1. для глобальных переменных

результат: 42856

2. кэш.

результат: 14999

как видно, для при записи одной переменной разница менее чем 3-кратная.


сейчас попробую проверить на более "реальных" ситуациях с большим кол-вом записей.

кстати, а ведь проявляются очень интересные вещи....

3. вызов функции.


результат: 33333

4. вызов функции с передачей/возвратом значения.



результат: 21428
(т.е. уже ровно в ДВА раза хуже простого присваивания)

5. вызовы функций типа "get / set"

результат: 18750
(всего на 25% быстрее кэша!)

наглядно видно, что тормознутость кэша в случае 2 обусловлена не столько временем работы native-функций, сколько затратами на их вызов.
(т.к. там механизм такой же, как и в случае 5)

DimonT добавил:
и, напоследок, чтобы окончательно "добить".

6. добавим get/set функциям список параметров от native-функций кэша:



результат: 8571
(в 1.5 раза МЕДЛЕННЕЕ кэша)

вот так вот..

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

вопрос тормознутости при больших объемах сохраняемой информации пока остается открытым.

Результаты беглого тестирования:
(!)- действие Move Unit начинает тормозит при 200 применениях за каждые 0.05. Т.е. больше 200 юнитов двигать триггерно нецелесообразно!
- действие записи/чтения в кешь тормозит при 2000 примнений, не тормрозит при 1000.
- действие созданить точку и удалить точку тормозит при 2000 применений
- действие вычислить синус тормозит при 5000 применений
(!)- действие call ExecuteFunc(...) тормозит при 1000 применений.
- операции со строками(сложение строк, перевод числа в строку) - тормозит после 4000 применений
- изменить высоту юнита - слегка притормаживает при 2500 применениях
(!)- условный оператор с одним условием проверки - притормаживает при 2000 применениях
(!)- перебор юнитов в группе, состоящей из 1 человека - ощутимо приормаживает уже при 1000 применений
- действие issue order damage target - тормозит при 2000 применений
- действие move region притормаживает при 5000 применений.

Итого: каждая из этих функций может фигурировать в триггере с малым периодом. Тот факт, что такие триггеры тормозит кешь считаю опровергнутыми. Обычно для кеша хватает 3-7 применений на 1 юнит. Но сколько еще других операций есть в каждом скрипте? Любая из них не более, чем в 2-4 раза быстрее кеша, а некоторые - так гораздо медленнее! Проверки условий, вычисление каких-то функций, работа с группами, вызов функций - все это тормозит сильнее кеша.

Это и есть ответ для тех, кто приводит Seal Master, как пример торможения кеша. Не кешь там тормозит, а сложный и длинный алгоритм + перемещение большого числа юнитов действием move unit.

Выод спецам-jass -ерам: упрощайте алгоритмы. Это единственный надежный способ ускорить скрипт.

Sergey добавил:
Димон, еще один потрясающий факт: торможение не имеет прямого отношения к числу максимально возможных применений!

К примеру, зациклив до бесконечности действие move unit максимальное число применений составит ~24000.
Для действия r = sin(1) это число будет всего лишь ~16000. НО! при выполнении цикла с действием move unit игра затормозит на несколько секунд, а при вычислении синусов все будет мгновенно. Причем даже если время перемножить в 1.5 раза, все равно получится гораздо меньше времения ожидания, чем для move unit.

ВЫВОД: команды скриптов отличаются друг от друга не только максимальным числом применений (которое можно вычислить), но и реальной скоростью выполнения (которую можно определить лишь на глазок).

Sergey, я это уже обнаружил...

итак, есть два разных, не связанных между собой метода торможения:
1. лимит действий, по исчерпании которого игра убивает поток.
вызов любой native-функции отнимает одинаковое количество таких операций.
такое "торможение" легко можно точно измерить для любого куска скрипта, что и было проделано выше.
2. обычное торможение, воспринимаемое "на глазок".
его точно измерить невозможно, только вызывать каждую функцию по неск. тысяч раз и сравнивать приблизительное время работы...

так вот.

с кэшом же проявляются еще более интересные вещи.

оказывается, сильнее всего тормозят следующие операции:
- запись НОВОГО ключа, тормознутость растет пропорционально общему числу записей.
(если в функции разом добавлять по 10000 новых записей, то каждый последующий ее вызов у меня выполнялся на 2-3 сек дольше предыдущего)
- первая попытка чтения любого ключа, в том числе несуществующего.

НО! следующие операции работают быстро (тормоза даже при работе с 10000 записей подряд не заметны):
- модификация записи с ранее использовашимся ключом;
- чтение уже однажды прочитанной записи (даже если она модифицировалась).


прикладываю тестовую карту, на которой все это измерял...
желающие могут сами попробовать дважды набрать строчку "write 0 10000" и убедиться, что на второй раз тормозить будет меньше.
(каждый раз сохраняются случайные числа под последовательно идущими ключами)

DimonT брр, а native функции самые низкие по цене? или у них цена просто для всех константа?

Ну это можно обьяснить тем что при записи нового ключа - фактически расширяется кэш (может там индексация или поиск/сортировка проходят). А первая попытка - фик его знает, может там используются хеш-таблицы?! Эти предположения обьясняют пункты "НО!"

Да, я такое же при повторной инициализации инва наблюдаю...

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

Димон,ты конечно говоришь сам о себе "лентяй", но чтобы настолько... :)

Твои дикие виспы с периодом 0.02 секунды создают и уничтожают по 1 спецэффекту. Еще спецэффект создается при столкновении виспа с врагом.

Я протестировал спецэффекты в триггерах с малыми периодами. Если период 0.05, то всего лишь 10 создаваемых и уничтожаемых создаваемых спецэффектов тормозят игру очень сильно. Я в твоем скрипте просто отключил спецэффекты и тормоза исчезли даже при 60 виспах. Точнее некоторые тормоза наблюдаются - но они другого рода. Не стоит забывать - у тебя на экране 30 крипов и 15 виспов и герой, и все движутся. Если снизить число крипов, то тормоза также исчезнут даже при большом количестве виспов.

Димон, лень тебя подвела :). Проще было сделать отдельный юнит - быстрый висп с отдельной моделью. Уже этого достаточно, чтобы убрать тормоза.

--------
Попутно я получил довольно интересные для jass-еров результаты. Дело в том, что юнит можно двигать действием MoveUnit, но есть и другое действие - SetUnitX, SetUnitY. Оказывается, что эти действия ГОРАЗДО быстрее, чем MoveUnit. Если MoveUnit тормозит при 200 применениях, то SetUnit... тормозят где-то при 600 и более числе применений. Так что делать много движущихся объектов возможно.

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

Вывод: на данный момент времени набиболее быстрый алгоритм перемещения юнита-снаряда без торможения достигается таймерами + командами SetUnitX, SetUnitY. Кстати, именно такой метод и реализован в wisp swarm.

Другие факты, которые удалось откопать:
1. Я несколько ошибся с оценкой тормознутости условий. Если брать условный оператор на jass без вызова левых функций, то для торможения нужно использовать 10000 условных операторов каждые 0.05 секунд. Впрочем, функции внутри оператора, очевидно, также снижают скорость. Т.е. скорость ограничена в основном скоростью используемых в проверке функций.
2. В варе обнаружились и другие методы торможения. Например, периодически с большой частотой менять цвет юнита, то игра вроде бы не тормозит. Но если перекрашиваемфый юнит начнет двигаться - все повиснет на жутких тормозах.
Еще открыт такой вот баг: я создавал и удалял n триггеров с событием timer expires. Если число n=200, то игра почти мгновенно зависает. Если n=50, то игра игра зависает, но не сразу, а постепенно. Причем такое поведение наблюдается только для динамически создаваемых триггеров таким событием. Похоже на какой-то баг разработчиков.
Правда, динамически создавать триггеры с таким событием вряд ли кому-нибудь понадобится.

вот сколько раз я, интересно, писал, что тормозят там именно эффекты, а не что бы то ни было еще.
только тормоза напрямую зависят от модели спецэффекта, поэтому точно измерять здесь что-то невозможно..