RM
Artöm Bakri Al-Sarmini
Сортировка обеспечивается алгоритмом обхода. При изменении дерева оно балансируется
Итерации по дереву слишком дорогие
Size: a a a
2020 April 05
AB
так, стоп. а когда ConfigManager превратился в TaskManager?
Скоро увидим gnu manager collection
AZ
Итерации по дереву слишком дорогие
AZ
звучит как ещё одна задача для профилирования
RM
Я провел небольшие тесты у себя, если учесть что я планировал итерироваться в loop по всем существующим сущностям: monsters, effects, players, то в худшем случае мой сервер, который отвечает за локацию и механику боя будет иметь 25000 Entity (это при условии, что одному серверу будет выдано поддержка нескольких локаций)
RM
В итоге, итерации по вектору показывает что итерироваться даже по 25к объектам не тратит у меня почти никакого времени
RM
Но тут есть еще один момент
IO
А какие ограничения у клиента по количеству объектов?
RM
В действительности нет необходимости итерироваться между всеми Entity, а так же Task в TaskManager при тиках. Для Entity, например, существует переменная отвечающее за время, когда у данного Entity должен вызваться Callback с Update
RM
Тем самым, маловероятно что даже заспавнив 1к объектов разом мы получим у всех Entity одно и тоже время
AZ
А какие ограничения у клиента по количеству объектов?
as much as possible :)
MB
Я понимаю что там древо, оно автоматом сортируется ?
То, что оно отсортировано - это его инвариант. Когда в сет вставляется ключ, он так поменяет структуру своего дерева, чтобы дерево осталось отсортированным. Как именно это происходит - зависит от того, какое именно дерево используется.
RM
Так что тут можно сделать некую погрешность, итерации по прежнему будут по 25к Entity, но вот выполняться callback функции будут лишь у десятка из них, а это понижает сложность в методе Tick
RM
Нет необходимости каждый тик выполнять callback'и у Entity и обрабатывать их логику, для существ достаточно делать это каждые 0.05 мсек к примеру или даже 0.1
RM
То, что оно отсортировано - это его инвариант. Когда в сет вставляется ключ, он так поменяет структуру своего дерева, чтобы дерево осталось отсортированным. Как именно это происходит - зависит от того, какое именно дерево используется.
Древо вроде сортируется в зависимости от того, какое значение у ключа, Если ранее ключ был A, то вставляя AB оно поместится в A разветвление
RM
Вроде так это устроено
AZ
Древо вроде сортируется в зависимости от того, какое значение у ключа, Если ранее ключ был A, то вставляя AB оно поместится в A разветвление
тебе уже сказали - зависит от дерева
RM
Так как поступить? В данный момент в моем TaskManager используется std::map, но его итерации дорогие
RM
Да я понимаю что он уже отсортирован, но это не меняет той сути что создав разом N задач они все попытаются вызваться в один тик
RM
Что если прибегнуть к той же тактике что и с Entity? Что если не сортировать вектор, а просто итерироваться по нему проверяя, настало ли время вызывать задачу, если да - вызываем