@Mike Комментарии к вашему коду: 1. Да, учитывая, что размер генома - около 3.2 гигабайтов, хранять в памяти 13 гб на весь геном можно себе позволить. 2. Не понял из ответа, правда, что выгоднее при запуске процесса - заново проиндексировать геном или считать индексные файлы?

@ViktorTomilov Смотря как использовать. С диска оно быстрее поднимается чем индексировать при запуске. Кроме того я отражаю файл на память (mmap) и ОС при старте вообще не читает все с диска, а делает это по мере моих обращений. Но поиск в принципе был бы быстрее, если бы в основном индексе были прямые указатели в памяти на списки. сейчас там смещения, следовательно дополнительный уровень косвенности в адресации. Но надо посмотреть что из этого компилятор делает.

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

Ну и с другой стороны, если оперативки много (у меня 500 Мб на тестовой машине свободных не было часть свапилась) и запуск происходит редко то можно и индексировать при старте. Особенно это потребуется если нет способа быстро сериализовать и десиарилизовать структуру.

@Mike Де факто, пригодным для биоинформатики компьютер считается, если на борту минимум 16 Гб памяти. По крайней мере, любой коммерческий продукт просит именно столько.

@ViktorTomilov Кстати, при увеличении индексируемого файла растет и количество существующих комбинаций и растут списки. рост списков замедляет скорость поиска, но рост комбинаций делает оправданным увеличение длины ключа. добавление 1 буквы в ключ уменьшает размеры большинства списков вдвое (это сказывается на скорости, но не объеме, списков то то же больше становится