ARSV/reimplement/plans.md

1. set.c используется в двух местах - rpm и rpm-build

   • в rpm используется только rpmsetcmp, который оборачивается в setcmp и используется как бинарник
   • в rpm-build используются оставшиеся 4 функции для создания, оборачиваются в бинарник mkset

2. Логично, что всю логику работы при таком исходе можно разделить

   • вероятно, начать стоит с составления (хотя хочется с сравнения, ибо 1 функция)

3. Другой вывод - бинарник, вообще говоря, можно написать и на другом ЯП в таком случае

4. Реимпементация не будет предполагать оптимизации, которая и не особо нужна при создании, но была бы полезна при сравнении

5. Используещиеся в данный момент оптимизации:

   • кэширование "левых" (provides) строк
   • pre-compiled таблица 2хбайт символов
   • прыжки по 4/8 символов хэша

6. Что можно было бы оставить из оптимизаций в сравнении:

   • теоритически кэш
   • прыжки сделать длиной len(s1)/len(s2)

7. Оптимизации при создании строк:

   • сторонняя хэш функция
     • также даёт преимущество на 64 бит хэше ("на всякий")
     • пока что всё равно остановимся на 64

8. Возможно изменение структуры кода для читаемости, например:

   • много init функций
   • много проверок, ошибки с отрицательными значениями

9. А какую реализацию оставляем?..

notes

все оптимизации с таблицей более не имеют смысла, т.к. раскодирование сразу по 6 бит гарантированно И даже если такую делать, то размер бинаря +19 Мб. А вот создание хэша для такого теоритически возможно.

!!! lib/rpmds.c стоит исследовать, т.к. сейчас есть шанс, что это единственное место, где используется оптимизация кэширования, если исользуется вовсе