кажется тащить гуаву, ради одной коллекции, это жестко%)
Вообще это для бэка надо. На вебсокетах. Есть пара, где сессия это ключ, значение это некоторое событие в котором участвуют другие пользователи. Когда в одну сессию прилетает пакет данных, я по сессии нахожу событие и что-то с ним делаю. Далее нужно всех юзеров оповестить об изменениях. То есть для каждого юзера найти сессию и отправить им пакет данных. А сессия - это ключ в таблице. Хочу снизить сложность алгоритма с O(n) до O(1)
Тоже думаю что гуаву тащить для этого так себе идея. Поэтому смотрю в сторону двунаправленного словаря. Вроде МАП можно нехитрым способом расширить
Хотяяя... есть другая идея. Передавать юзер айди в заголовке. А мапу структурировать как <UserId, ClassWithEventWithSessionWithParticipants>>
Вощм временно сделал вот так fun Map<K, V>.getKey(value: V) : K? = entries.associate { it.value to it.key }[value] Хотя это один проход по списку, в любом случае O(n)
чисто из интереса, это те самые двусвязные списки где каждый элемент хранит ссылку на соседние? а то когда смотрел базовые курсы еще по питону, я думал что это нигде вообще не применить в прикладном программировании или это не то?
не не, это не то. Вот ты в мапе находишь значение по ключу, сложность O(1). То есть неважно насколько большая мапа, время выполнения операции от размера мапы не зависит. А вот если у тебя есть значение, и тебе нужно найти под каким ключом она лежит, то тебе надо перебором найти тот самый entry в мапе и вернуть его ключ. Тут скорость выполнения операции будет сильно зависеть от размера мапы. Поэтому под капотом таки хструктур как правило две мапы, они синхронизированы. там на каждое entry создается два экземпляра <K, V> и <V, K>. если очень поверхностно, на деле все сложнее
понял, но по описанию всеж похоже на то что каждый элемент хранит ссылку на какую-то позицию, но лучше не буду ворошить, а то я не сталкивался в практике
Обсуждают сегодня