start on newset.c

2026-07-13 20:36:30 +03:00
parent 58dcef4a21
commit b1e47622ae
3 changed files with 86 additions and 0 deletions
@@ -0,0 +1,31 @@
+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 бит хэше ("на всякий")
+
+8. Возможно изменение структуры кода для читаемости, например:
+   - много init функций
+   - много проверок, ошибки с отрицательными значениями
+
+9. А какую реализацию оставляем?..
+
+!!! `lib/rpmds.c` стоит исследовать, т.к. сейчас есть шанс, что это единственное место, где используется оптимизация кэширования, если исользуется вовсе