Неоптимальный поиск по файлу в 3 параллейных потоках

Здравствуйте, Уважаемые!

если позволите, я сразу к сути:

-есть файл, в нем - 40 000 строк (2,5Мб и будет расти дальше, но не более 20Мб=200-250тыс.строк) - это такая импровизированная БД (формат записи строк в ней - предельно простой: ключ+разделитель+значение)
-при старте программы этот файл полностью загружается в объект TStringList (глобальная переменная)
-при старте программы этот файл загружается в TStringList (полностью)
-запускается 3 потока, каждый из которых обращается к этому TstringList и выполняют в нем поиск строк по собственному списку (каждого поток проверяем прим. по 10-15тыс.строк)
Важно: потоки выполняют поиск обычным циклом FOR и ф-ии Pos, пробегая по всем строкам объекта TStringList пока не встретится похожая, или не будет проверены все строки объекта. после чего выставляет либо запоминает строку кот.не нашлась, либо (если была найдена строка) - просто делает следующую итерацию проверки...
Как оказалось (по средствам проведенных мною тестов и замеров) - это самый быстрый вариант, но об этом ниже...)

Вроде бы работает, НО есть то, что меня беспокоит:

1. не страшно ли то, что обращение из потоков к общему для всех объекту TStringList выполняется - НА ПРЯМУЮ? (никакой синхронизации, критических секциций и т.п.)
я рассудил так, что - раз потоки ничего не записывают и не меняют в объекте, а только считывают из него инфу - то и конфликтов никаких быть не может! даже
если два потока попытаются считать одну и ту же запись одновременно (ведь по сути - потоки это все равно псевдо-параллейная работа, после переключения -
выделения кванта времени конкретному потоку - он все равно, в эту единицу времени, фактически работает - ОДИН!..) --- или я ошибаюсь?

2. Возможно ли увеличить скорость проверки - если для каждого потока создавать собственную копию объекта, чтобы они работали не с единым объектом в памяти, а
каждый со своей копией! (4Gb оперативки - позволяют) - может будет меньше конфликтов (если таковые имеются) и общая скорость проверки возрастет?

3. на данный момент общее время выполения всех проверок (на ноутбуке - 2 физ.ядра (2,1GHz) +2 виртуальных, память 4GB )
в 1 поток = 16 мин. (при выполнении - загрузка CPU в переделах 40-60%)
в 3 потока = 9 мин.
в 4 потока = почти те же 9 мин. --- т.е. дальнейшее увеличение кол-ва потоков уже не ускоряте процес... - Почему?

4. На данный момент поиск выполняется прямым перебором в цикле FOR с использованием функции Pos() - как оказалось это самое быстрое решение!
до этого пытался использовать встроенное средство TStringList.Values['тут искомая строка-ключ'] (т.е. поиск по имени ключа - записи в файле
как раз в этом формате, с нужным разделителем) - но оказалось скорость падает просто КАТАСТРОФИЧНО - общее время выполения,
в те же 3 потока - выполнялись 41мин!!!! (почти в 5 раз больше!!!) - Почему так? (так и не понял! + загрузка CPU держалась на уровне 92-99%)
поэтому и вернулся к обычному циклу FOR...

Что еще можно придумать?
Mожет есть более грамотное и изящное решение (с точки зрения производительности)?

Уважаемые знатоки, посоветуйте что-нибудь...