AHK: Можно ли ускорить парсинг?

Ок. Подробно.

Есть 1000 файлов. В них в  каждой строке в виде трёх чисел от 000 до 256 записаны RGB-цвета точек квадрата 500х500 точек.
  Для примера:

  Всего получается 250 000 строк.

Задача. Нужно найти точки с определёнными критериями и проверить точки, которые их окружают.
Допустим в координатах
x125 y358
есть чёрная точка и нужно проверить сколько ещё таких же точек есть вокруг неё.  Т.е. нужно проверить квадрат 3х3 с углами в точках  x124 y357 и  x126 y358.

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

Сначала я  читал файлы с помощью
Loop, Read,
а проверял соседние точки  с помощью
FileReadLine

Очень медленно.

Стал читать файл целиком с помощью
FileRead,
и проверял соседние точки  с помощью
FileReadLine

Очень медленно. Я грешил на  FileReadLine, и сделал иначе.

Читаю сейчас сразу файл в переменную и все строки загоняю в отдельные переменные

...
FileRead, text_file, %A_LoopFileFullPath%

Loop , Parse, text_file, `n
 {
 stroka%A_index% :=  A_LoopField
 }
...

  А потом уже проверяю нужные строки на соответствие условиям, используя готовые значения в пронумерованных переменных.

Долго. 4-6 секунд на файл. 1000 файлов - более 80 минут. После проверки оказалось, что основную массу времени занимает именно парсинг - 4.5 секунд.

Ничего более подходящего для этой процедуры в справке не нашёл. 

Можно ли как-то ускорить сам парсинг?  Может есть какие-то глобальные настройки или что-то другое?

Ну во первых применить 

SetBatchLines -1

увеличит скорость в 3-4  раза.

зачем?

FileRead считать все файлы в одну переменную, далее RegExMatch. Должно быть быстрее.

Как узнать адрес для StrGet так и не понял.   

Адрес переменной, куда считан файл, узнаётся оператором &.

addr := &Var

Это и будет адрес буфера с текстом. Прибавьте к нему смещение нужной строки от начала и получите её адрес. Если версия AutoHotkey юникодная, то каждый символ занимает 2 байта. Между строками два невидимых символа, возврат каретки и перевод строки, т.е. 4 байта. Если версия не юникодная, тогда считайте по 1 байту на символ.

Вот для примера две функции, получающие цвет по координатам и координаты по цвету. Написаны в предположении, что АНК юникодный и точки квадрата в файле описаны ряд за рядом, а не колонка за колонкой.

file = d:\prog\temp\colors.txt
FileRead, buf, %file%

color = 241014233

If CoordsFromColor(color, x, y)
    MsgBox, X: %x% Y: %y%
Else
    MsgBox, Цвет не найден

ColorFromCoords(color, x, y)

MsgBox, Color: %color%


CoordsFromColor(color, ByRef x, ByRef y)
{
    global buf
    pos := InStr(buf, color)
    If (pos = 0)
        Return False
    pos := (pos - 1) // 11
    x := Mod(pos, 500)
    y := pos // 500
    Return True
}

ColorFromCoords(ByRef color, x, y)
{
    global buf
    addr := &buf + (y * 500 + x) * 22
    color := StrGet(addr, 9)
}

Видимо я глуп. Но мне надо объяснять на цифрах (алгоритме). На пальцах (картинках) я не пойму. Вы сейчас предлагаете мне выработать некий новый алгоритм вычисления. Или объяснить свой?
Я не вижу отношения к приведённым ранее "текстам".

У вас есть одна строка (весь текст 250 файлов), в которой надо найти нужную цифру.?
Дальнейшие критерии поиска остальных строк, исходя из найденной - мне всё таки не ясны.
Картинки это хорошо. Работаем то с текстом.
Как в строке с набором цветов, определяется их принадлежность к координатам.?

По алгоритму, думаю можно смотреть ответ YMP. Из того что я понял в этом коде я делаю вывод, что он всё понял правильно.

Ускорять обработку (читай: оптимизировать) нужно не с середины, а с начала, если имеется такая возможность. Возникает вопрос о происхождении текстового файла с цветами точек, заданными к тому же в десятичном, а не в HEX формате, что было бы еще как-то понятно. Использование именно такого варианта обусловлено какими причинами, если не секрет? Дело в том, что если описать этот массив точек в двоичном формате (4 байта на точку - для скорости), то файл займет меньше мегабайта, что уже даст прирост по скорости чтения.  А загрузив его в переменную, можно извлекать цвета нужных точек посредством NumGet, или же вообще поручить это процедуре в машинных кодах, получив значительный прирост в производительности скрипта.

Все же рекомендую отказаться от многоступенчатых преобразований туда-сюда, при первой возможности. По поводу "что я делаю неправильно" :

d := A_IsUnicode ? 22 : 11
FileRead, text_file, %A_ScriptDir%\str.txt
addr := &text_file - d
loop 200
   MsgBox % "Stroka: " . StrGet(addr+=d, 9)

в коде поста #19 исправил первую строку )) Почему-то вместо "22 : 11" отправил вариант "16 : 8"

YMP, тогда уж

addr := addr + 22

иначе при каждой итерации addr будет прирастать на всё бОльшую величину, а не на фиксированный шаг.