Какой должна быть скорость парсера pyrogram?

Question

[brexer74]

Недавно написал телеграм парсер на Pyrogram. Отрабатывает 10к сообщений (ну т.е получает юзеров которые писали в чат) за 3 минуты. Это хорошая скорость, или её можно существенно увеличить?

Comments

[Сергей Соловьев]

мы то откуда знаем

[brexer74]

Сергей Соловьев, ну вдруг знаете

[chemdev]

brexer74, можно увеличить

[Dmitrii]

Какая у вас стоит задача? И для кого она?
Достаточная ли это скорость для решения этой задачи?
Какие цели у парсера и как его можно оптимизировать, а главное зачем?
Есть ли задача парсить в реальном времени?
Какие вычислительные ресурсы вам доступны?

Ускорить вычисления всегда возможно, например, банально распараллелив задачу (многопоточность, многопроцессорность).

[SynapticWhisper]

Dmitrii, многопоточность это, конечно, хорошо, жалко только в Python есть такая штука как GIL, и какого-то глобального прироста в производительности получить не получится. Если парсер большую часть времени проводит в ожидании ответа, то да, прирост по сравнению с синхронным выполнением будет, но дело в том что Pyrogram - асинхронный фреймворк, поэтому разницы между синхронным выполнение в нескольких потоках (Threading) и выполнением через async или совсем не будет, или threading даже притормозят код.
Есть еще multiprocessing, но там тоже не все так однозначно.
При желании можно погонять это все в тестах и выявить победителя, но я бы глянул в сторону оптимизации кода, если производительность не устраивает

[Dmitrii]

SynapticWhisper, странно, если парсер проводить большую часть времени в ожидании. Про GIL я в курсе. Опять же никто не мешает подумать в сторону cpython или вообще переписать часть кода на другом языке/написать либу. Как я говорил выше все упитается в то какая стоит задача.

[SynapticWhisper]

Dmitrii, my bad, проводит большую часть времени в ожидании ответа от сервера, а не просто простаивает)
cpython - если я ничего не путаю, а я вроде не путаю - это дефолтная версия питона.
Ну судя по тому что автор спрашивает, нормальную ли он получил производительность, он сам не очень понимает, какая ему нужна производительность, поэтому писать библиотеку на чем нибудь супер-мега быстром смысла в данном случае нет)
Ну а если вдруг прирост в производительности таки нужен, то я бы перед тем как хвататься за другие языки в попытках ускорить свой код, порекомендовал бы, сначала все таки попробовать оптимизировать алгоритмы обработки данных и тд, потому что в 99% случаев, код работает недостаточно быстро, потому что мы его таким написали, а не потому что упирается в производительность языка.
Ну и ИМХО узким горлышком в данном случае будет как раз таки ожидание ответа от сервера, будь то код на плюсах или на петухоне, сервер будет отвечать одинаково долго)

[Dmitrii]

SynapticWhisper, пишем качественный бенчмарк, в котором мокаем сервер и вуаля наши синтетические цифры готовы к тому чтобы ими хвастаться)
Но да, в целом, я с вами согласен)

Answer 1

[Laiwer]

В офицальной документации есть упоминание об увеличении скорости (ссылка). Там говорится про uvloop и он увеличивает работу asyncio в 2-4 раза, а значит и работу Pyrogram. Я пробовал его использовать, но столкнулся с проблемой: uvloop не работает на Windows. Так что если у вас парсер работает на Windows - ничего не выйдет.
Асинхронность самый быстрый вариант.