Является ли мультиинтерфейс в curl быстрее или эффективнее, чем использование нескольких простых интерфейсов?

Вы пытаетесь оптимизировать то, что вообще не имеет значения.

Если вы хотите загрузить 200 URL-адресов как можно быстрее, вы потратите 99,99% своего времени на ожидание этих 200 запросов, что ограничено вашей сетью и/или сервером(-ами), с которого вы загружаете. Ключом к оптимизации является правильное количество одновременных запросов. Все, что вы можете сделать, чтобы сократить последние 0,01%, не окажет видимого влияния на вашу программу. (См. Закон Амдала.)

Разные источники дают разные рекомендации, но обычно это где-то между 6-12 запросами, не более 2-4 на один и тот же сервер. Поскольку вы извлекаете их все из Google, я бы предложил начать с 4 одновременных запросов, а затем, если это недостаточно быстро, настроить это число, пока не получите наилучшие результаты.

Что касается места, стоимость хранения 200 страниц будет намного превышать стоимость нескольких десятков байтов здесь и там для накладных расходов. Опять же, вы хотите оптимизировать эти 200 страниц — сохраняя их на диск, а не в память, анализируя их по мере поступления, вместо того, чтобы загружать все, а затем анализировать все и т. д.

В любом случае, вместо того, чтобы смотреть, какие инструменты командной строки у вас есть, и пытаться найти библиотеку, похожую на них, ищите библиотеки напрямую. pycurl может быть полезен в некоторых случаях, например, когда вы пытаетесь сделать что-то сложное и уже знаете, как это сделать с помощью libcurl, но в целом будет намного проще использовать либо модули stdlib, такие как urllib, либо третьи Модули для вечеринок разработаны максимально простыми, например, requests.

основной пример для ThreadPoolExecutor в документации показывает, как делать именно то, что вы хотите сделать. (Если вы используете Python 2.x, вам потребуется pip install futures, чтобы получить резервную копию для ThreadPoolExecutor, и использовать urllib2 вместо urllib.request, но в остальном код будет идентичным.)

Наличие нескольких простых интерфейсов, работающих одновременно в одном потоке, означает создание собственного реактора и управление curl на более низком уровне. Это болезненно в C и столь же болезненно в Python, поэтому libcurl предлагает и рекомендует multi.

Но здесь ключевое значение имеет «в том же потоке». Вы также можете создать пул потоков и добавить в него простые экземпляры. В C это все еще может быть болезненно; в Python это очень просто. На самом деле, первый пример в документации по использованию concurrent.futures.ThreadPoolExecutor делает что-то похожее, но на самом деле более сложное, чем вам нужно здесь, и это всего лишь несколько строк кода.

Если вы сравниваете мульти и простой с ручным реактором, простота является основным преимуществом. В C вы могли бы легко реализовать более эффективный реактор, чем тот, который использует libcurl; в Python это может быть правдой, а может и не быть. Но в любом языке затраты производительности на переключение между несколькими сетевыми запросами будут настолько малы по сравнению со всеми остальными вашими действиями, особенно ожиданием этих сетевых запросов, что вряд ли когда-либо будут иметь значение.

Если вы сравниваете многопоточность и простоту с пулом потоков, то реактор определенно может превзойти потоки (за исключением платформ, где вы можете связать пул потоков с проактором, как с портами завершения ввода-вывода Windows), особенно для огромных чисел. одновременных подключений. Кроме того, каждому потоку нужен собственный стек, что обычно означает выделение около 1 МБ страниц памяти (хотя не все они используются), что может стать серьезной проблемой в 32-разрядной среде для огромного количества подключений. Вот почему очень немногие серьезные серверы используют потоки для соединений. Но для клиента, который устанавливает несколько подключений, все это не имеет значения; опять же, затраты, связанные с потерей 8 потоков по сравнению с использованием реактора, будут настолько малы по сравнению с реальными затратами на вашу программу, что они не будут иметь значения.