Как быстрее скачивать?

Я бы создал поток, который может читать один URL-адрес и обрабатывать его содержимое. Затем вы можете решить, сколько из этих потоков вы хотите запускать одновременно. Ваш компьютер будет допускать большое количество подключений, поэтому, если эти 100 сайтов имеют разные имена хостов, не проблема запустить 10 или 20 одновременно. Слишком много - перебор, а слишком мало - пустая трата времени процессора.

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

Потому что в настоящее время у вас есть другие проблемы. Во-первых, это не делается для использования компонентов VCL в потоке. Если вам нужна информация из списка в потоке, вам нужно будет либо использовать Synchronize в потоке, чтобы сделать «безопасный» вызов основного потока, либо вам придется передать необходимую информацию перед запуском потока. Последнее более эффективно, потому что код, выполняемый с использованием Synchronize, фактически выполняется в основном потоке, что снижает эффективность многопоточности.

Но на самом деле мое внимание привлекла первая строка: «загрузить исходный код веб-страницы в компонент памятки». Не делай этого! Не загружайте эти результаты в памятку для обработки. Автоматическую обработку лучше всего выполнять в памяти, за пределами визуального контроля. Использование строк, потоков или даже списков строк для обработки текста намного быстрее, чем использование заметок.
Список строк также имеет некоторые накладные расходы, но он использует ту же конструкцию индексации строк (TMemoStrings, которое является свойством Lines Memo, и TStringList имеют одного и того же предка), поэтому, если у вас есть код, который использует этого будет довольно легко преобразовать в TStringList.

Я бы посоветовал выполнять ВСЕ синтаксический анализ в потоках, чтобы основной поток вообще не выполнял синтаксический анализ. Основной поток должен управлять только пользовательским интерфейсом. Не анализируйте HTML из TMemo, загружайте каждый поток в TStream или String, а затем выполняйте синтаксический анализ напрямую из них. Используйте TIdSync или TIdNotify для отправки результатов синтаксического анализа в пользовательский интерфейс для отображения (если важна скорость, используйте TIdNotify). Включение компонентов пользовательского интерфейса в логику синтаксического анализа замедлит его.

Indy или Synapse готовы к многопоточности. Я бы рекомендовал использовать Synpase, который намного легче, чем Indy, и его будет достаточно для ваших целей. Не забывайте о HTTP API, предоставляемых Microsoft.

Простая реализация:

• Один поток на URI;
• Каждый поток получает данные, используя одно соединение HTTP;
• Затем каждый поток анализирует данные;
• Затем используйте Synchronize, чтобы обновить пользовательский интерфейс.

Пожалуй, мой любимый:

• Определите максимальное количество используемых потоков (например, 8);
• Каждый из этих потоков будет поддерживать удаленное соединение (это цель HTTP / 1.1 и действительно может повлиять на скорость);
• Все запросы извлекаются этими потоками один за другим - не назначайте URL-адреса заранее потокам, но извлекайте новый URL-адрес из глобального списка, когда поток завершил его (каждый URL-адрес не всегда занимает одно и то же время);
• Потоки могут ждать, пока любой другой URI не будет добавлен в глобальный список (например, используя Sleep(100) или семафор);
• Затем проанализируйте и обновите пользовательский интерфейс в основном потоке графического интерфейса, используя специальное сообщение GDI (WM_USER+...) - анализ будет быстрым IMHO (и помните, что обновление пользовательского интерфейса может быть медленным - взгляните, например, на BeginUpdate-EndUpdate методы) - я обнаружил, что сообщение GDI (со связанными данными HTML) более эффективно, чем использование Synchronize, которое блокирует фоновый поток;
• Другой вариант - выполнить синтаксический анализ в фоновом потоке сразу после получения данных из его URI - возможно, того не стоит (только если ваш синтаксический анализатор медленный), и вы можете столкнуться с проблемами многопоточности, если ваш синтаксический анализатор / процессор данных не на 100% потокобезопасен.

Во-вторых, как реализованы популярные так называемые «менеджеры загрузки».

Когда вы имеете дело с многопоточностью, вам придется «защищать» ваши общие ресурсы (например, списки). Используйте TCriticalSection для доступа к любому глобальному списку (например, списку URI) и снимите блокировку как можно скорее.

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