76 lines
3.5 KiB
Markdown
76 lines
3.5 KiB
Markdown
# Другой дизайн
|
||
|
||
## Roaring map
|
||
|
||
По крайней мере в примитивном варианте скорость создания остаётся примерно прежней, скорость сравнения становится кратно меньше
|
||
|
||
Также кратно выше становится сама длина строки
|
||
|
||
```text
|
||
symbols=1000 required=500 bpp=32
|
||
implementation set_chars format
|
||
set9 3994 golomb
|
||
bitmap 19924 R1
|
||
```
|
||
|
||
```text
|
||
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
|
||
|
||
```text
|
||
symbols=1000 required=500 bpp=32
|
||
implementation set_chars format
|
||
set9 3994 golomb
|
||
bitmap 14126 R2
|
||
```
|
||
|
||
без zstd строка становится ~40% длинее
|
||
|
||
```text
|
||
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, можно получить лучшую работу с кжшом
|
||
- (надеюсь, что под капотом оно уже и так это делает, но проверить стоит)
|