Unryze, не раз замечал как люди пытаются обойти функцию IsTerrainPathable путём проверки проходимости предметом (SetItemPosition) или юнитом (SetUnitPosition), по привычке сам начал использовать проверку предметом, можно об этом тоже пару слов добавить

Unryze, смешно получается, суть как раз была что IsTerrainPathable медленнее чем сместить тот же предмет, спрятать его, а потом сравнивать координаты предмета и нужной точки
даже откопал старый вопрос с комментариями от сильных людей: xgm.guru/p/wc3/168497

---

а, стоп, IsTerrainPathable имеет ещё один косяк если не ошибаюсь, оно не проверяет по нормальному проходимость путей от декораций

---

раскрыть

Скопировать в буфер

    local item it = CreateItem( 'spsh', 500.00, 500.00 )
    local real x
    local real y
    
    call CreateDestructable( 'ATtr', 0.00, 0.00, 270.00, 1.00, 0 ) 
    
    call SetItemVisible( it, false )
    
    if not IsTerrainPathable( 0.00, 0.00, PATHING_TYPE_WALKABILITY ) then
        call BJDebugMsg( "IsTerrainPathable: проходимо" )
    else
        call BJDebugMsg( "IsTerrainPathable: непроходимо" )
    endif
    
    call SetItemPosition( it, 0.00, 0.00 )
    call SetItemVisible( it, false )
    set x = GetItemX( it )
    set y = GetItemY( it )
    
    if ( x + 1.00 < 0.00 or x - 1.00 > 0.00 ) or ( y + 1.00 < 0.00 or y - 1.00 > 0.00 ) then
        call BJDebugMsg( "Предмет: непроходимо" )
    else
        call BJDebugMsg( "Предмет: проходимо" )
    endif

Unryze, про хэш-таблицу ещё был миф, что это огромный объект, который лучше больше одного раза не создавать, даже в статье на этом сайте было написано об этом.

	globals
		location Loc
	endglobals

	function DoSomething takes nothing returns nothing
		local location l
		set Loc = Location(0., 0.)
		set l = Loc
	endfunction

Unryze, ещё кое-что интересно, работа с темповой группой
что быстрее: делать всё в цикле без булекспра или делать всё в булекспре? бенчмарк вовсе минусовый результат показывает, но вероятно тут проблемы уже моего компа

раскрыть

Скопировать в буфер

globals
    private constant group TempG = CreateGroup( )
    private unit bj_lastFilterUnit = null
endglobals

native UnitAlive takes unit id returns boolean

private function cond takes nothing returns boolean
    set bj_lastFilterUnit = GetFilterUnit( )
    if UnitAlive( bj_lastFilterUnit ) then
        call SetWidgetLife( bj_lastFilterUnit, GetWidgetLife( bj_lastFilterUnit ) )
    endif
    return false
endfunction

function TestBenchmarking takes nothing returns nothing
    local integer p     = 0
    local integer i     = 0
    local integer time  = 0
    local unit u
    local boolexpr b = Condition( function cond )
    
    set i    = 0
    set time = GetLocalTime( 0 )
    loop
        exitwhen i == 10000
        call GroupEnumUnitsInRect( TempG, bj_mapInitialPlayableArea, null )
        
        loop
            set u = FirstOfGroup( TempG )
            exitwhen u == null
            call GroupRemoveUnit( TempG, u )
            if UnitAlive( u ) then
                call SetWidgetLife( u, GetWidgetLife( u ) )
            endif
        endloop
        
        // Some stuff here
        set i = i + 1
    endloop
    set time  = GetLocalTime( 0 ) - time
    call DisplayTextToPlayer( GetLocalPlayer( ), 0, 0, "First Delay: " + I2S( time ) + "ms" )
    
    set i    = 0
    set time = GetLocalTime( 0 )
    loop
        exitwhen i == 10000
        call GroupEnumUnitsInRect( TempG, bj_mapInitialPlayableArea, b )
        // Some other stuff here
        set i = i + 1
    endloop
    set time  = GetLocalTime( 0 ) - time
    call DisplayTextToPlayer( GetLocalPlayer( ), 0, 0, "Second Delay: " + I2S( time ) + "ms" )
endfunction

---

> мы СОЗДАЁМ переменную и присваиваем её в локальную переменную
Создаём объект

---

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

Ладно, тогда почему тут всё удаляется, а потребление ОЗУ растёт? В твоих примерах с группой и локацией переменная обнуляется.

https://xgm.guru/p/wc3/do-unnulled-handle-locals-leak#h3

---

Скопировать в буфер

	globals
		location Loc
	endglobals

	function DoSomething takes nothing returns nothing
		local location l
		set Loc = Location(0., 0.)
		set l = Loc
	endfunction

Вот это утекает?

PT153, ну ссылка локальной же не обнуляется, утекает значит

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

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

https://xgm.guru/files/100/281579/comments/485859/2022-05-02_02-...

Карту прилагаю.

Unryze:

pGameWar3 = *(pGameDLL+0xab65f4)
pGameState = *(pGameWar3+0x1c)

pGameState+0x194 - сколько мест в таблице выделено
pGameState+0x198 - сколько мест в таблице занято
pGameState+0x19с - Массив структур, хранящих количество ссылок на хэндл, указатель на объект, и, возможно, еще что-то.
pGameState+0x1A0 - Шаг повышения размера таблицы.

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

Строго говоря, утечка в 3?! байта - не критично, но за несколько часов, при достаточном усердии, можно набрать достаточно. Но в коротких играх, вероятно, источником проблем такая утечка не будет.

А безопасности, в рамках моего понимания, необнуление не даст, так как по сути, если на сущность нет ссылок на хэндл, а сама сущность удалена - нет никаких способов с ей провзаимодействовать или пострадать от её отсутствия.

	globals
		location Loc
	endglobals

	function DoSomething takes nothing returns nothing
		local location loc
		set Loc = Location(0., 0.)
		set loc = Loc
	endfunction

globals
    location Loc = Location( 0., 0. )
endglobals

function TestFunctionEx takes nothing returns nothing
    local location loc = Loc
endfunction

function TestFunction takes nothing returns nothing
    local integer i = 0
    
    loop
        exitwhen i > 1000
        call TimerStart( CreateTimer( ), .01, true, function TestFunctionEx )
        set i = i + 1
    endloop
endfunction

globals
    hashtable HashTable = InitHashtable( )
    location Loc = Location( .0, .0 )
endglobals

function TestFunctionEx takes nothing returns nothing
    local unit u = LoadUnitHandle( HashTable, 123, 321 )
endfunction

function TestFunction takes nothing returns nothing
    local integer i = 0
    
    call SaveUnitHandle( HashTable, 123, 321, CreateUnit( Player( 0 ), 'Hpal', 0., 0., 270. ) )
    
    loop
        exitwhen i > 1000
        call TimerStart( CreateTimer( ), .01, true, function TestFunctionEx )
        set i = i + 1
    endloop
endfunction

Смотри видео внимательно, оно потом падает, ибо проходят и другие действия. Оно не растёт без конца. Оно ещё и падает
Предоставленный код тобою - утекает лишь в случае если его повторять и не удалять используемый объект.

05070000 -> local handle
00000487 -> её id
0C290500 -> literal register (type) location
13290000 -> push register
0C2A0500 -> literal register (type) location
132A0000 -> push register
15000000 -> callnative
00000314 -> id нативки
11000000 -> setvar
00000F7D -> id переменной
0E2B0700 -> get var register (type) Handle
00000F7D -> id переменной
112B0000 -> setvar register
00000487 -> id переменной
0E2C0700 -> get var register (type) Handle
00000F7D -> id перемнной
132C0000 -> push register
15000000 -> callnative
00000315 -> id нативки
0C000000 -> literal R0
27000000 -> return

05070000 -> local handle
00000487 -> её id

05070000 -> local (type) handle
00000487 -> id переменной

	globals
		location Loc
	endglobals

	function DoSomething takes nothing returns nothing
		local location loc
		set Loc = Location(0., 0.)
		set loc = Loc
	endfunction

		OPCODE_VARIABLE_NOTHING = 0,   // "nothing"
		OPCODE_VARIABLE_UNKNOWN,       // "unknown"
		OPCODE_VARIABLE_NULL,          // "null"
		OPCODE_VARIABLE_CODE,          // "code"
		OPCODE_VARIABLE_INTEGER,       // "integer"
		OPCODE_VARIABLE_REAL,          // "real"
		OPCODE_VARIABLE_STRING,        // "string"
		OPCODE_VARIABLE_HANDLE,        // "handle"
		OPCODE_VARIABLE_BOOLEAN,       // "boolean"
		OPCODE_VARIABLE_INTEGER_ARRAY, // "integer array"
		OPCODE_VARIABLE_REAL_ARRAY,    // "real array"
		OPCODE_VARIABLE_STRING_ARRAY,  // "string array"
		OPCODE_VARIABLE_HANDLE_ARRAY,  // "handle array"
		OPCODE_VARIABLE_BOOLEAN_ARRAY, // "boolean array"

"Судя по твоему тесту с юнитов - утечек не будет."

"Я так понял, проблема с локалками возникает в том случае, если в функции создаётся хендл.
То есть, если создаётся хендл, то ЛЮБУЮ локалку этой функции, в которой этот хендл находится или находился в процессе выполнения функции, нужно обнулить."

Unryze, есть миф, что if then {без кода} else {код} endif быстрее, чем if not then {код} endif. Я так и не получил утвердительного ответа на вопрос — так ли это?
Извиняюсь, если спрашиваю уже баянистую тему.

Сравнение байткода

Байткод func1

0C1A0800 -> literal register (type) bool
261A0000 -> not register
2A1A0000 -> jmpf register
000012AD -> label для прыжка
16000000 -> calljass (вызов джасс функции, операция схожа с callnative)
00000A93 -> id функции
2B000000 -> jmp
000012AE -> label id прыжка
28000000 -> label
000012AD -> id label'а
28000000 -> label
000012AE -> id label'а
0C000000 -> literal R0
27000000 -> ret

Байткод func2

0C1B0800 -> literal register (type) bool
2A1B0000 -> jmpf register
000012AF -> label для прыжка
2B000000 -> jmp
000012B0 -> label id прыжка
28000000 -> label
000012AF -> id label'а
16000000 -> calljass (вызов джасс функции, операция схожа с callnative)
00000A93 -> id функции
28000000 -> label
000012B0 -> id label'а
0C000000 -> literal R0
27000000 -> ret

Результат скорости

Ярг Восьмой, бред какой-то

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

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