Другой дизайн

Roaring map

По крайней мере в примитивном варианте скорость создания остаётся примерно прежней, скорость сравнения становится кратно меньше

Также кратно выше становится сама длина строки

symbols=1000 required=500 bpp=32
implementation  set_chars  format
set9                3994  golomb
bitmap             19924  R1

operation                 set9       bitmap   bitmap/set9
set_fini only           266.24 us  202.89 us         0.76x
new+add+fini           1696.05 us 1600.44 us         0.94x
rpmsetcmp cold          293.87 us 1321.17 us         4.50x
rpmsetcmp warm            5.24 us  399.20 us        76.14x

Использование zstd

symbols=1000 required=500 bpp=32
implementation  set_chars  format
set9                3994  golomb
bitmap             14126  R2

без zstd строка становится ~40% длинее

operation                 set9       bitmap   bitmap/set9
set_fini only           171.84 us  314.20 us         1.83x
new+add+fini           1185.33 us 1726.32 us         1.46x
rpmsetcmp cold          285.04 us 1412.84 us         4.96x
rpmsetcmp warm            4.82 us  490.94 us       101.86x

хранить сразу расшифрованный set

огромная часть ресурсов уходит не на просмотр включения множеств, а на декодирование set-строк
- при возможности хранить больше данных за более дешёвое сравнение - прекрасно
- тупо условный формат:
  - <bpp> <последовательно упакованные bpp-битные хеши>
Shannon–Fano–Elias coding как одна из идей, но надо глубже копать

Группировать, а не хэшировать

если была бы возможность точно делать соответствия между label и id, то provides стал бы в большинстве последовательным, а required было бы легко искать в P.

Доработки на текущий дизайн

битовый prefilter

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

улучшить проход по массивам

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

Прочие улучшения

улучшение работы с хэшем

если условно "отсортировать" массив provides/requires, можно получить лучшую работу с кжшом
- (надеюсь, что под капотом оно уже и так это делает, но проверить стоит)

3.5 KiB Raw Blame History Unescape Escape