Python-сообщество

Дано: быстрый 1Tb NVMe SSD от Samsung

Нужно: выжать максимальную скорость при загрузке кеша (больших коллекций обьектов - классы со slots)
На старте пайтон программы, загружаются самописные индексы, по ним производится поиск, отдается результат.
Сами коллекции можно как угодно переписать, в том числе в виде библиотеки на Rust (но хотелось бы сначала выжать максимум из пайтона)

Посоветуйте что можно попробовать?
Есть также рамдиск для тестов

Отредактировано NVMeMaster (Июль 20, 2021 22:46:13)

NVMeMaster
Посоветуйте что можно попробовать?

NVMeMaster
Нужно: выжать максимальную скорость при загрузке кеша

Я думаю нужно читать и писать кеш в том же самом формате в каком он находится в оперативной памяти.
А чтобы эффективнее упаковать данные нужно использовать С или Rust массивы.
Как можно написать класс-обертку для превращения С-массива в рид-онли питон список?

> На старте пайтон программы, загружаются самописные индексы, по ним производится поиск, отдается результат.

Ничего не понятно. Какие индексы? Где они хранятся? Как хранятся данные на диске? В каком формате? Каким образом питоновские объекты записываются на диск?

Отредактировано Rodegast (Июль 22, 2021 12:38:37)

В данный момент оно реализовано на простом pickle

Мне нужен быстрый поиск по ~8Gb текстовых файлов, логика поиска примерно такая же как в нотпад++
Только у меня индексы строятся заранее, а не в момент поиска.
Содержимое файлов загружается лениво (предпросмотр сделан на pyqt5 точно как на скриншоте. но графический режим и предпросмотр используется не всегда)


Если попытаться перевести скриншот в сишную структуру получится следующее:
struct SearchResult {
int file_path_hash; //file_path_hash == Python hash(file_path)
int str_start_index;
int line_number; //добавлено для предпросмотра в стиле нотпад++
int line_str_start_index; //для предпросмотра в стиле нотпад++
}

find_string будет именем файла, ну а содержимое файла - массив структур

Как видно я совсем отказался от хранения строки с file_path.
Вместо имени файла храню хеш пути к файлу и использую словарь int file_path_hash -> file_path в отдельном файле. (эту логику не нужно переписывать с Python на си)

Сейчас нужно компактно упаковать struct SearchResult в памяти.
А поскольку я выбросил все строки можно попробовать хранить это все в ПЛОСКОМ numpy.array
Вот так оно сериализуется в файл:

 arr = np.array([
    2147483647, ord('a'), ord('b'), ord('c'),
    2147483647 - 1, ord('q'), ord('w'), ord('e'),
    2147483647 - 2, ord('a'), ord('s'), ord('d'),
    2147483647 - 3, ord('z'), ord('x'), 2147483647
])
file_name = 'np_array.dat'
np.save(open(file_name, 'wb'), arr)

Отредактировано NVMeMaster (Июль 22, 2021 13:33:35)

Мне нужен быстрый поиск по ~8Gb текстовых файлов

Вокруг моего решения уже выстроено много кастомной логики, отказаться от нее не выйдет.

Если делать np.save() / np.load() в разных потоках это решит все проблемы.
В идеале - на каждый файл индекса - свой поток, но не более некоторого максимального числа потоков.

В следующей итерации индексер файлов можно написать на Rust, просто имитируя формат файлов с np.array
Как думаете стоит ли заморачиваться с numpy, или же сразу написать библиотеку-обертку над сишной или Rust структурой и массивами

Отредактировано NVMeMaster (Июль 22, 2021 13:54:32)

NVMeMaster
Как думаете стоит ли заморачиваться с numpy, или же сразу написать библиотеку-обертку над сишной или Rust структурой и массивами

NVMeMaster
Нужно: выжать максимальную скорость

NVMeMaster
Сейчас нужно компактно упаковать struct SearchResult в памяти.

NVMeMaster
Вокруг моего решения уже выстроено много кастомной логики, отказаться от нее не выйдет.

NVMeMaster
Мне нужен быстрый поиск по ~8Gb текстовых файлов, логика поиска примерно такая же как в нотпад++

NVMeMaster
Сами коллекции можно как угодно переписать, в том числе в виде библиотеки на Rust

doza_and
Вы не приводите никаких требований ни по быстродействию ни по объему памяти, вообще никаких.