Основываясь на ветке комментариев к OP, я добавлю предложение сюда.
При работе с большими объемами данных обычно более эффективно сначала каким-либо образом сортировать данные, а затем использовать что-то вроде двоичного поиска для поиска блоков данных.
Например, вы упоминаете, что хотите сравнить элементы в одном списке с элементами во втором списке. Для этого я буду считать, что размер первого списка (список А) маленький, а второй (список Б) большой.
Если элементы в списке B упорядочены по некоторому ключу, например, по названию округа (при условии, что все округа имеют уникальное имя), вы можете использовать Алгоритм двоичного поиска , чтобы найти случайный (по существу) элемент в блоке записей для округа, а затем, в зависимости от количества записей для любого данного округа, вы либо сделаете 2 цикла, чтобы найти верхнюю и нижнюю границу, либо другой бинарный поиск, либо аналогичный для другого ключа, по которому список будет Приказ должен быть указан после оригинального ключа (например, общего объема), в результате чего у вас будет список только тех элементов, которые соответствуют определенной вами метрике.
Если данные еще не отсортированы, вероятно, стоило бы их отсортировать, поскольку сложность по времени для Heapsort или Quicksort в худшем случае O (nlogn), а в двоичном поиске - в худшем случае O (logn). Временная сложность зацикливания ваших списков, вероятно, была бы порядка O (kn ^ k) или чего-то еще, что, если бы вы строили график, было бы во много раз хуже.
Что касается последней части вашего вопроса, то понимание списка - это просто синтаксический сахар и ничего особенного не делает.
tldr; сортируйте данные по некоторому уникальному идентификатору, я рекомендую использовать Heapsort , так как он на месте, универсальный, так как вы можете предоставить функцию сравнения, и она будет работать с этим, и вы, вероятно, можете найти итеративную реализацию в Python. Затем используйте бинарный поиск для эффективного поиска предметов.
Надеюсь, это поможет!