GavriKos

Ну из непосредственных.
Можно заранее для каждой пары строк вычислить нужный процент, и как только его превысили - сразу выходить из цикла сравнения посимвольного. Причем даже не процент, а количество совпадений. Это может дать прирост в ряде случаев.

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

Можно еще подумать насчет оптимизации хранимых строк. Например, заменить ненули на количество пропусков цикла. Т.е. число 0011100 записать как 00300, и уже при итерировании учитывать эту тройку как +=3.

Это так, что быстро в голову пришло

Можно. И питон и JS в этом плане норм. Нюанс разве что в том что в том же питоне будет много синтаксического сахара - но вы его можете игнорировать.

C# в целом можно выучить быстренько для ваших потребностей. А вот плюсы оставьте в покое.

Ну про квадрат расстояния уже сказали.
Далее - tuples проинициализируйте каким то количеством. Потому что на Add при аллокации съедите много времени.
Ну перебор конечно конский - посчитайте количество итераций, их многовато как то ) Но тут вряд ли что то сделаешь, хз. Надо читать задачу. Может можно ограничить эти итерации.
Дальше. Не видно где меняется x и что это такое, но выглядт так что Math.Pow(i - x, 2) можно вычислить до внутреннего цикла.

Я бы еще попробовал убрать Create у тупли - тоже аллокация.

НАсчет ГПУ. У вас кроме корня (который не нужен) судя по всему нет дробных чисел (хотя мы не знаем что такое x и y) - поэтому именно использование ГПУ тут не даст космического прироста. А вот второй цикл похоже можно распараллелить. На чем параллелить - без разницы

Я ведь прав, что использование математики дешевле использования операторов? =.=

Очень спорный момент, но условные операторы крайне дешевые.
Если мы говорим не о шейдерах.
А преждевременная оптимизация - крайнее зло.

Классная задача.
Я бы нагенерил (скорее всего руками - чтобы красиво было) много шаблонов - а ля "кварталы" ток поменьше, а потом из них уже клеил город.

Если прям надо процедурно - то начинать надо пожалуй с дорог - у них есть четкие требования а-ля граф, где вершины это районы (наверное).

Ну и пара статей:
https://habr.com/ru/company/piter/blog/455004/
https://habr.com/ru/post/320140/ (да, это лабиринт а не город - но общие черты есть)

Начать строить дерево вызовов для каждой функции. Как только при добавлении очередного вызова где то выше по дереву уже есть вызов этой же функции - вот вам и рекурсия.

Сложность простого поиска -n
Сложность бинарного поиска - Log(n)
А вот скорость быстрой сортировки неконстантна, и в худшем случае составляет n^2.

Так что однозначного ответа нет. Все зависит от входных данных.
Однако, если поиск делается часто, а данные не меняются (т.е. можно один раз отсортировать) - то определенно быстрее бинарный поиск.

Обосновывается это все математикой и ничем другим.