Уже есть хороший ответ @MattH, сфокусированный на деталях Python по вашей проблеме, и, хотя его можно улучшить в нескольких деталях, улучшения принесут вам лишь несколько процентных пунктов эффективности - стоит, но не очень.
Единственная надежда на огромное повышение эффективности (в отличие от постепенного улучшения "кай-дзен") - это радикальное изменение в алгоритме - которое может или не может быть возможным в зависимости от характеристик ваши данные, которые вы не раскрываете, и некоторые подробности о ваших точных требованиях.
Важная часть: примерно, какой диапазон чисел будет присутствовать в файле, и примерно, сколько чисел в разделе "d.complex.N"? Вы уже сказали нам, что будет около 2000 строф на файл (и это, конечно, также важно), и создается впечатление, что в каждом файле они будут упорядочены непрерывным увеличением N - 1, 2, 3 и так далее (это так?).
Ваш алгоритм строит две карты строфы-> числа (не с максимальной эффективностью, но ответ @ MattH фокусируется на улучшении), так что неизбежно ему нужны N squared
проверки строфы-строфы - так как N равно 2000, это нужно 4 миллиона таких проверок.
Рассмотрим создание перевернутых карт, чисел-> строф - если диапазон чисел и типичный размер (количество чисел в) строфе разумно ограничены, они будут более компактными. Например, если числа находятся в диапазоне от 1 до 200, а в строфах около 4 чисел, это означает, что число обычно будет в (2000 * 4) / 200
-> 40 строфах, поэтому в таких сопоставлениях будет 200 записей по 40 строф в каждой. Требуется только 200 квадратов (40000) проверок, а не 4 миллиона, чтобы получить объединенную информацию для каждого числа (тогда, в зависимости от точной потребности в формате вывода, форматирование этой информации может потребовать очень существенных усилий снова - если вам абсолютно необходимо как конечный результат 4 миллиона «секций-пар» в качестве выходных данных, тогда, конечно, нет способа избежать 4 миллионов «выходных операций, что неизбежно будет очень дорогостоящим).
Но все это зависит от тех цифр, о которых вы не говорите - средней численности строфы и диапазона чисел в файлах, а также от деталей того, какие ограничения вы должны абсолютно соблюдать для выходного формата (если числа разумно, ограничения выходного формата станут ключевым ограничением производительности big-O, которую вы можете получить из любой программы).
Помните, чтобы процитировать Фред Брукс :
Покажите мне свои блок-схемы и скрыть
ваши таблицы, и я буду продолжать
быть мистифицированным. Покажи мне свои столы и
Мне обычно не нужны ваши блок-схемы;
они будут очевидны.
Брукс писал в 60-х годах (хотя его сборник «Мифический человеко-месяц» был опубликован позже, в 70-х годах), откуда странное использование «блок-схем» (где мы будем говорить код или алгоритмы) и «таблицы» (где мы бы сказали, данные или структуры данных) - но общая концепция все еще остается в силе: организация и характер ваших данных во всех видах программ, ориентированных на обработку данных (таких как ваша ), может быть даже более важным, чем организация кода, тем более что он ограничивает последний; -).