38 lines
2.7 KiB
Markdown
38 lines
2.7 KiB
Markdown
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` стоит исследовать, т.к. сейчас есть шанс, что это единственное место, где используется оптимизация кэширования, если исользуется вовсе
|