Unryze:

40 байт единожды потерять, не знаю даже.

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

Непонятно какая речь про жалкость 40 байт, если люди умудряются память даже точками засрать, которые казалось бы имеют размер еще меньше.

Суть в том, что если есть объект, который можно создать, но нельзя удалить, это утечка. В варе такого дофига.

Спустя 10 лет еще кому-то не пофиг? Вообще я в комментах отвечал, что имелось в виду.
У нас нет действия типа DestroyHashtable, то есть таблицы нельзя удалять. Поэтому если в каком-то действии постоянно создаются таблицы, память будет течь.

Unryze:

То бишь 0x34 байта выделены всегда, каждая ХТ по стандарту - это 0x28 байт опять, и каждая новая ячейка - 4 байта (исключение boolean (1 байт) и string (каждый символ = 1 байт)).

Здесь главный вопрос деаллокается ли память обратно при удалении элементов. Если да, то утечку памяти хотя бы можно минимизировать очисткой. Если нет, то это вообще жопа и мое утверждение верно на 100%.

Вот вам кусок кода.

https://www.xgm.guru/files/100/281579/comments/486703/HashvsArra...

Взято отсюда.

https://www.hiveworkshop.com/threads/hashtable-vs-array.289909/#...

> Приведу в пример ту же систему снарядов, ты же что-то будешь проверять, чтобы убедиться что снаряд нужно двигать, верно?
это всё равно что после выгрузки юнита из хэш-таблицы проверять, что он != null

цикл не делается от 0 до 8191, он делается от минимального и максимального значения, которое варьируется от кол-ва "запусков", если что-то не нужным становится, на его место ставят последнее, а максимальное значение снижают на единичку

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

---

массив по индексу никто не проверяет на != null

---

может мне пример работы с циклом и одним таймером показать, вместо хэштаблицы как используют

JackFastGame:

думаю стоит доработать её, а именно информацию о ресурсоёмкости хэш-таблиц

Что за ресурсоёмкость

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

---

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

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

---

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

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

Unryze:

Как-то очень поверхностно что ли прочитал статью, процитирую кусочек: "Рассмотрим их фактические задержки, 3 мс / 10000 = 300 наносекунд и 13 мс / 10000 = 1300 наносекунд, то бишь борьба идёт за 1000 наносекунд, что является 0.001 мс или же 0.000001 секунды. Потому мне лично сложно представить, где эта разница даст о себе знать и как часто делается 10000 повторов или же вызовов чего-либо."

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

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

Забыл добавить, что я писал не о просто "сткрутурах" в целом, а при применении их в MUI наработках. Ну и хочется добавить, что лимит строго по индексу - куда хуже, чем возможность использовать уникальный хендл объекта как ключ, что убирает мягко говоря геморрой индексации.

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

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

все еще быстрее

Unryze, про хэш-таблицу как я понял все мифы из этой статьи пошли: xgm.guru/p/wc3/hashtable

так а где развенчивание мифа про то что хеш таблица медленная? ты же это сам и показал, кек, лишь подтвердив что она реально медленнее

Unryze, ну тут скорее тема обсуждения: насколько критично плодить обёртки ради читаемости и поддерживаемости кода)

Ещё ходил такой слушок, что вызов функции из другой функции несёт дополнительную нагрузку на JASS-машину. Этот миф появился из-за bj-функций, которые в себе вызывают аналогичную нативную функцию.

function ClearTextMessagesMy takes nothing returns nothing
    call ClearTextMessages( )
endfunction

Для ХП баров ничего не завезли? Вообще как-то можно получить указатель на хп-бар юнита, или всё гораздо сложнее и нужна отдельная DLL?

Супер! Спасибо огромнейшее, исчерпывающе.

Правильно ли я понимаю, что герою такая способность не даст ничего?

Кстати я говорил об Amim способность, но я так думаю она идентична

можно равкод абилки?

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

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

Unryze, Ага, то есть, как я понимаю, иконки настраиваются в коде игры, видимо в game.dll ?
Я то хотел не просто расположение иконок поменять, а сделать панель приказов на 20 иконок, 5х4 чтобы было, ну и с размерами иконок чуть поменьше. И без мемхака, чтобы не было возможных дополнительных проблем. Чтобы такая панель была вшита в игру, как стандартная.

А что находится в game.dll?

Функция ReduceAbilityCooldown иногда работает только визуально: на UI кулдаун уменьшается, но кулдаун самой абилки при этом не изменился, и даже когда на UI уже нет кулдауна, абилка всё равно будет говорить, что пока нельзя применить. Это как-нибудь фиксится?

globals
    hashtable SpellCastTable = InitHashtable( )
endglobals

function AbilityEffectFunc takes nothing returns nothing
    local timer t = GetExpiredTimer( )
    local integer hid = GetHandleId( t )
    call SetAbilityCooldown( LoadAbilityHandle( SpellCastTable, GetHandleId( t ), StringHash( "Ability" ) ), 1., "" )
    call PauseTimer( t )
    call FlushChildHashtable( SpellCastTable, hid )
    call DestroyTimer( t )
    set t = null
endfunction

function AbilityUsedHandler takes integer aid, ability abil, unit caster, widget target, real targx, real targy returns nothing
    local timer t

    if aid == 'AOsh' then
        set t = CreateTimer( )
    endif

    if t != null then
        call SaveInteger( SpellCastTable, GetHandleId( t ), StringHash( "AbilityId" ), aid )
        call SaveAbilityHandle( SpellCastTable, GetHandleId( t ), StringHash( "Ability" ), abil )
        call SaveUnitHandle( SpellCastTable, GetHandleId( t ), StringHash( "Caster" ), caster )
        call SaveWidgetHandle( SpellCastTable, GetHandleId( t ), StringHash( "Target" ), target ) // Можно поменять на item/desctructable
        call SaveReal( SpellCastTable, GetHandleId( t ), StringHash( "TargetX" ), targx )
        call SaveReal( SpellCastTable, GetHandleId( t ), StringHash( "TargetY" ), targy )
        call TimerStart( t, .01, false, function AbilityEffectFunc )
    endif

    set t = null
endfunction

function AbilityUsed takes nothing returns nothing
    call AbilityUsedHandler( GetSpellAbilityId( ), GetSpellAbility( ), GetTriggerUnit( ), GetSpellTargetUnit( ), GetSpellTargetX( ), GetSpellTargetY( ) )
endfunction

function Init_TestAbilUsed takes nothing returns nothing
    local trigger t
    set t = CreateTrigger( )
    call TriggerRegisterPlayerUnitEvent( t, Player( 0 ), EVENT_PLAYER_UNIT_SPELL_EFFECT, null )
    call TriggerAddAction( t, function AbilityUsed )
    set t = null
endfunction