start on newset.c

This commit is contained in:
2026-07-13 20:36:30 +03:00
parent 58dcef4a21
commit b1e47622ae
3 changed files with 86 additions and 0 deletions
+52
View File
@@ -0,0 +1,52 @@
#include "system.h"
struct set {
int cnt;
struct symbols {
const char* str;
unsigned hash;
}* symbols_v;
};
struct set* set_new() {
// should we use x___ funcs?
struct set* set = xmalloc(sizeof *set);
set->cnt = 0;
set->symbols_v = NULL;
return set;
}
void set_add(struct set* set, const char* sym) {
const int delta = 1024;
if ((set->cnt & (delta - 1)) == 0) {
set->symbols_v = xrealloc(set->symbols_v, sizeof(*set->symbols_v) * (set->cnt + delta));
}
set->symbols_v[set->cnt].str = xstrdup(sym);
set->symbols_v[set->cnt].hash = 0;
set->cnt++;
return;
}
struct set* set_free(struct set* set) {
if (set) {
for (int i = 0; i < set->cnt; i++) {
_free((char*)set->symbols_v[i].str);
}
_free(set->symbols_v);
set = _free(set);
}
return NULL;
}
// ---
const char* set_fini(struct set* set, int bpp) {
// Implementation for finalizing the set
return NULL;
}
+31
View File
@@ -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` стоит исследовать, т.к. сейчас есть шанс, что это единственное место, где используется оптимизация кэширования, если исользуется вовсе