Саша Потёмкин
WarCraft 3

Что меньше влияет на память?

Добавлен
Вопрос, что лучше использовать реальные переменные или обычные цифры с вычислением, переменные юнитов или обычные функции? Что будет меньше вызывать нагрузку на память, вопрос бредовый но все же:)
call UnitDamageTarget(a,n,2*GetUnitAbilityLevel(a,'A00V'),false,false,null,null,null)
// или
local real damage = 2*GetUnitAbilityLevel(a,'A00V')
call UnitDamageTarget(a,n,damage,false,false,null,null,null)
//-------------------------------------------------------------------------------------------
call KillUnit(GetSpellAbilityUnit())
// или
local unit a = GetSpellAbilityUnit()
call KillUnit(a)
set a = null
Я думаю что вызыв и создание переменных нагружает больше чем уже встроенные функции, но всеравно интересно

бранчера в виртуалке жасса нет, а количество внутренних проверок рабочих объектов на каждом этапе так велико, что надеяться на "прогрев" нативок бессмысленно. Если используется больше одного раза - вбивай в локалку, если один раз - оставляй вызовом функции.
12 сен 2021
903
`
ОЖИДАНИЕ РЕКЛАМЫ...
2
Показать
28
2
Показать
Логично же, что первый вариант будет быстрее, т.к. при втором варианте у тебя происходит объявление переменной, запись в неё значения, а потом уже в функции идёт обращение к этой переменной и оттуда достаётся значение
Такая штука была бы быстрее, если бы ты юзал эти переменные не для одного действия, а нескольких, например вместо
call SetUnitX(GetTriggerUnit(), x)
call SetUnitY(GetTriggerUnit(), y)
call KillUnit(GetTriggerUnit())
лучше будет естественно так
local unit u = GetTriggerUnit()
call SetUnitX(u, x)
call SetUnitY(u, y)
call KillUnit(u)
set u = null
обращение к переменной быстрее вызова функции, но если ты создаёшь ради одного действия, то это не имеет смысла
0
Показать
14
0
Показать
rsfghd: 
call SetUnitX(GetTriggerUnit(), x)
call SetUnitY(GetTriggerUnit(), y)
call KillUnit(GetTriggerUnit())
иногда бывало что если не использовать переменную то триггер нефига не работал(на ГУИ) лучше все же использовать переменную а да с переменныме точно так же было не хаватала скорости не помню что я делал но точно знаю что переменные могут тормозить
как сказал <- xgm.guru/user/rsfghd если код короткий то можно без переменных(не всегда) а если длинный то без переменных никак
0
Показать
28
0
Показать
Гуванч, есть тест бенчмарк на мх, если уж хочется узнать какие действия будут быстрее других
0
Показать
14
0
Показать
rsfghd:
Гуванч, есть тест бенчмарк на мх, если уж хочется узнать какие действия будут быстрее других
да не чел меня все устраивает просто прочитав твой коммент вспомнил что баги были у меня без переменных и с переменными
0
Показать
15
0
Показать
Разница настолько мала, что лучше вообще так не делать.
Не убивайте читабельность в угоду мнимой производительности. Оптимизация и архитектура проекта эффективны по Парето, поэтому ищите золотую середину.
2
Показать
26
2
Показать
имеет смысл инлайнить если там меньше чем пару вызовов, если больше - забивать в переменные лучше
потому что вызов нативок тоже не бесплатный, и постоянно дергать оттуда данные если там их вызовов 10 не комильфо
0
Показать
32
0
Показать
Hate, мало того вызов нативок некоторых достаточно медленный бывает, ладно проверка уровня абилки не такая сдоупочная...
0
Показать
38
0
Показать
Вы не учли, что бранч предиктор это может порешать) хотя что ждать от жасса.
2
Показать
16
2
Показать
бранчера в виртуалке жасса нет, а количество внутренних проверок рабочих объектов на каждом этапе так велико, что надеяться на "прогрев" нативок бессмысленно. Если используется больше одного раза - вбивай в локалку, если один раз - оставляй вызовом функции.
Принятый ответ
2
Показать
38
2
Показать
DracoL1ch, бранч предикшн не в виртуалках, а в железе и работает с любыми вычислениями, советую изучить тему и потестировать, довольно полезно для саморазвития 👍
0
Показать
16
0
Показать
я понял, о чем ты, я говорю, что жасс не подгадаешь - в кишках простейших действий тысячи прыжков и обращений к самым разным областям памяти, т.к. байт-код исполняется еще и в "виртуалке". нет смысла играть в компилятор, достаточно делать те оптимизации, которые не противоречат общей логике.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.