Добавлен
У всех наследников типа widget есть такие функции как SetUserData и GetUserData. Хотелось бы иметь такую же функцию для таймеров.
Для этого я использую хеш-таблицу, но они медленные. Я бы создал массив, в качестве индексов используя хендлы таймеров, только хендлы больше, чем индекс ячеек.
Поэтому я хочу создать бинарное дерево, в каждой ячейке которого будет содержаться хендл таймера и UserData. Тогда GetTimerUserData будет состоять из бинарного поиска нужного хендла и вывода соответствующей UserData.
Но будет ли это быстрее, чем использование хеш-таблиц? Если нет, то есть ли ещё способы это реализовать?

Принятый ответ

спойлер - хештаблицы медленнее в сравнении с доступом по массиву. как только ты дописываешь еще пару строк к массиву (т.к. тебе надо вычислить ключ), внезапно хт становится быстрее. так что не мудри
нет ничего быстрее нативок. а каждая строка JASS-кода существенно замедляет работу. Экономия на спичках
2
32
6 лет назад
2
Ну структуру и любые аттачи, там не большая разница. И ниче там не медленное.
Вот пример как передавать локалки в поток таймера ссылка
0
17
6 лет назад
0
Как вам вообще в голову приходят такие вопросы. Каким образом ваш интерпретируемый Jass-костыль может работать быстрее нативного API движка?
2
16
6 лет назад
Отредактирован DracoL1ch
2
спойлер - хештаблицы медленнее в сравнении с доступом по массиву. как только ты дописываешь еще пару строк к массиву (т.к. тебе надо вычислить ключ), внезапно хт становится быстрее. так что не мудри
нет ничего быстрее нативок. а каждая строка JASS-кода существенно замедляет работу. Экономия на спичках
Принятый ответ
0
28
6 лет назад
Отредактирован PT153
0
DracoL1ch:
спойлер - хештаблицы медленнее в сравнении с доступом по массиву. как только ты дописываешь еще пару строк к массиву (т.к. тебе надо вычислить ключ), внезапно хт становится быстрее. так что не мудри
нет ничего быстрее нативок. а каждая строка JASS-кода существенно замедляет работу. Экономия на спичках
Ага, то есть
integer array DATA
...
local integer a = DATA[GetHandleId(timer)]
медленнее чем
hashtable DATA
...
local integer a = LoadInteger(DATA, GetHandleId(timer), 0)
Верно?
Я думаю, что нет, но суть понял, спасибо.
2
32
6 лет назад
2
PT153, одно обращение к хт = 2 обращения к массиву.
Структуры помогают только когда ты записываешь в хт индекс структуры, по которому и ищеш данные в массивах.
Для переодик таймера я уже кинул пример как еще можно, там вовсе локалки.
0
28
6 лет назад
0
quq_CCCP:
PT153, одно обращение к хт = 2 обращения к массиву.
Структуры помогают только когда ты записываешь в хт индекс структуры, по которому и ищеш данные в массивах.
Для переодик таймера я уже кинул пример как еще можно, там вовсе локалки.
widget можно дать кастомное число, и туда я записываю номер структуры. SetUserData быстрее доступа в хеш? Просто я хотел лишь иметь такую же функцию у таймеров.
0
32
6 лет назад
0
PT153, я тебе кинул такую функцию для таймеров. предеаешь инт в таймер, там будет просто локалка со значением, читай.
2
16
6 лет назад
2
нет, я же написал - ФУНКЦИЯ тяжелеее одного обращения к хт
чтобы найти ключ, тебе нужно произвести Х операций поверх GetHandleId()
а доступ к ХТ - 1 операцией
0
28
6 лет назад
0
quq_CCCP:
PT153, я тебе кинул такую функцию для таймеров. предеаешь инт в таймер, там будет просто локалка со значением, читай.
Это я понял, спасибо. я не очень хочу использовать мемхак как и любые другие баги вара.
PT153:
SetUserData быстрее доступа в хеш?
Хотелось бы это узнать.
2
32
6 лет назад
2
PT153, это какраз не баг, а недоработка jass интерпритатора, виртуальная Jass машина может передавать аргументы в каллбеки, это не является чем то не запланированным.
Мемхак нужен в самом минимальном исполнении. В статье описано что по чем и как устроено.
Проблем с работоспособностю быть не должно.
Чтобы оставить комментарий, пожалуйста, войдите на сайт.