Dmitrii, my bad, проводит большую часть времени в ожидании ответа от сервера, а не просто простаивает)
cpython - если я ничего не путаю, а я вроде не путаю - это дефолтная версия питона.
Ну судя по тому что автор спрашивает, нормальную ли он получил производительность, он сам не очень понимает, какая ему нужна производительность, поэтому писать библиотеку на чем нибудь супер-мега быстром смысла в данном случае нет)
Ну а если вдруг прирост в производительности таки нужен, то я бы перед тем как хвататься за другие языки в попытках ускорить свой код, порекомендовал бы, сначала все таки попробовать оптимизировать алгоритмы обработки данных и тд, потому что в 99% случаев, код работает недостаточно быстро, потому что мы его таким написали, а не потому что упирается в производительность языка.
Ну и ИМХО узким горлышком в данном случае будет как раз таки ожидание ответа от сервера, будь то код на плюсах или на петухоне, сервер будет отвечать одинаково долго)
Dmitrii, многопоточность это, конечно, хорошо, жалко только в Python есть такая штука как GIL, и какого-то глобального прироста в производительности получить не получится. Если парсер большую часть времени проводит в ожидании ответа, то да, прирост по сравнению с синхронным выполнением будет, но дело в том что Pyrogram - асинхронный фреймворк, поэтому разницы между синхронным выполнение в нескольких потоках (Threading) и выполнением через async или совсем не будет, или threading даже притормозят код.
Есть еще multiprocessing, но там тоже не все так однозначно.
При желании можно погонять это все в тестах и выявить победителя, но я бы глянул в сторону оптимизации кода, если производительность не устраивает
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
cpython - если я ничего не путаю, а я вроде не путаю - это дефолтная версия питона.
Ну судя по тому что автор спрашивает, нормальную ли он получил производительность, он сам не очень понимает, какая ему нужна производительность, поэтому писать библиотеку на чем нибудь супер-мега быстром смысла в данном случае нет)
Ну а если вдруг прирост в производительности таки нужен, то я бы перед тем как хвататься за другие языки в попытках ускорить свой код, порекомендовал бы, сначала все таки попробовать оптимизировать алгоритмы обработки данных и тд, потому что в 99% случаев, код работает недостаточно быстро, потому что мы его таким написали, а не потому что упирается в производительность языка.
Ну и ИМХО узким горлышком в данном случае будет как раз таки ожидание ответа от сервера, будь то код на плюсах или на петухоне, сервер будет отвечать одинаково долго)