Анализ и ускорение Медленного кода Python через cProfile и KCacheGrind
Vložit
- čas přidán 8. 07. 2024
- ⭐ Курс ООП и Приват канал: zproger-school.com/
⭐ Телеграм канал: t.me/+T6QZGzXUSZIwOWZh
Как сделать код на Python быстрее? Как найти функции, которые потребляют больше всего ресурсов?
Первый шаг - провести анализ вашего кода, через инструменты из данного видео. Использовать мы будем cProfile и его оболочку KCacheGrind, также мы рассмотрим пример выполнения байт-кода на низком уровне, чтобы понять почему некоторый код выполняется быстрее другого.
Профилировщик cProfile измеряет, сколько времени занимают все ваши вызовы функций, а затем вы можете распечатать или сохранить эту статистику, чтобы определить, на что вы должны потратить свое время для улучшения. Вы можете поднять свое профилирование на новый уровень с помощью графического инструмента из этого видео.
📁 Github: github.com/Zproger
📁 Все плейлисты с уроками: bit.ly/39GaY89
📁 Связаться со мной: zproger777@gmail.com
📁 Поддержать криптовалютой: github.com/Zproger/donate
Тайм-коды:
0:00 - Вступление
0:30 - Что медленнее. Цикл while или for?
1:54 - Как определить какая функция быстрее через cProfile?
3:05 - Почему цикл for работает быстрее?
3:28 - Исследуем циклы while и for через Python дизассемблер dis
4:30 - Как работает цикл while на низком уровне?
5:15 - Как работает цикл for на низком уровне?
6:01 - Устанавливаем kCacheGrind
6:44 - Запускаем интерфейс анализатора kCacheGrind
7:40 - Как проанализировать функции в интерфейсе kCacheGrind?
8:45 - Как посмотреть граф вызовов функций Python?
9:13 - Исследуем структуру встроенных библиотек Python
9:38 - Почему важно делать оптимизацию кода?
Тема оптимизации очень обширная и довольна нужная тема, жаль большинство ей пренебрегают, спасибо за такой качественный контент!)
Ага, многим проще сказать что Python медленный, чем найти решение)
Мега полезная тема для глубокого изучения алгоритмов)
Спасибо!
но ведь это разница между скоростью циклов, при увеличении нагрузки тела цикла она не должна увеличиваться, просто прибавится (время выполнения тела цикла)*(кол-во итераций) в оба типа цикла
При большом объеме кода, как говорится в видео, например обращение к БД Разница будет такая же 7 сек.
При условии, что выполняемый код будет идентичен. Тут показана разница именно в цикле. И скорее всего из-за операции сравнения.
Если Добавить операцию сравнения в тест2, то возможно разница будет меньше.
Мысль была в том, что если оставить такое количество итераций на действиях, которые потребляют больше ресурсов, то в итоге чем больше итераций мы сделаем, тем больше будет разница между этими циклами.
Когда изначально мы делали 1млн итераций, разница составляла несколько миллисекунд, на значении же в 100млн итераций, разница составила 6 секунд, в итоге тяжелые операции сделают скорость выполнения ниже, и это количество приведет к огромной разнице в циклах.
@@zproger Чувак, НЕ БУДЕТ разница больше! Подумай ещё раз хорошенько. Рано ты взялся за объяснение вопросов производительности...
Спасибо! Было познавательно!
Благодарю за поддержку!
А видео класс, мне нравится
Спасибо
Привет! Спасибо за твои уроки. Очень полезно и интересно. Продолжай в том же духе :)
Рад что помогает, благодарю за фидбек
Круто, спасибо!
:)
Редкий контент на Ютубе, очень круто 🔥🔥
Это мотивирует меня, спасибо!
Спасибо
Рад что было полезно :)
С ростом времени исполнения содержимого циклов, в вашем случве, относительная разность времени их исполнения стремится к 0. ;)
Ага, но если бы это был не инкремент, то была бы совершенно другая картина :)
@@zproger без разницы. Потому, что эти циклы будут отличаться только способом модификации индекса. А он, не зависит от тела цикла. ;)
Кажись легче код почистить, чем уж так
Вообщем, я давно за тобой наблюдаю, и решил подписаться, довольно интересные ролики делаешь, желаю успехов и сил
Благодарю, буду стараться :)
делай больше видео про оптимизацию python
Учту, спасибо :)
Идея для следующего видео, встрой авторизацию в свой мессенджер
Там как раз таки фишка в том, чтобы не использовать любые средства,
которые могут идентифицировать клиента, но спасибо за идею :)
Здравствуйте. Спасибо большое за видео про оптимизацию. В нынешнее время не все разработчики заботятся об оптимизации, т.к. менеджеры очень торопят их из-за дедлайнов перед руководством.
Со своей стороны, как главный инвестор игры, где ты типа грибок и прыгаешь по супермарио, хотелось бы сказать, что предоставлю Вам достаточно времени для оптимизации этой игры, т.к. нам необходимо охватить бо́льшую аудиторию, чем у любых других ААА-игр. Надеемся на Ваш опыт, что Вы не подведете и игра будет выдавать стабильные 60 фпс с ровным фреймтаймом.
Не подведу, спасибо xDD
Можно написать функцию декоратор, для расчёта время функции.
Делать параллельные вычисления.
А для математических расчётов хорошо подходит numpy и numba.
Например, попробуй, на чистом питоне посчитать сумму первых 2 миллионов и более простых чисел и посмотри сколько времени, это занимает)
Полезная информация, спасибо :)
Я так сделал мало пользы когда интересно узнать за сколько времени работает бинарный поиск из ляма чисел всего 24 прохода. Меньше наносекунды
Для справки, на rust цикл while на миллиард 1 000 000 000 занимает менее 4 секунд.
А вот for уже 19секунд, разница почти в 5 раз.
Странно, я пока такие тесты с Rust не делал, надо будет глянуть =)
потому что надо делать while (i--), должно быть быстрее
В питоне нет такого декремента :)
@@zproger -= 1, инкремента тоже нет
Чел)) Ты тоже это начал пользовать?)
Я KCacheGrind первый раз пользовал для пыхи 🌚
Привет, спасибо за видео! Скажи, пожалуйста, почему выбрал именно linux Mint?
Удобный и простой, сейчас правда уже для видео пересел на Zorin OS, его бы не стал
использовать как основной дистрибутив, но для видео самое то.
Сними про библиотеку numba, там код на питоне приобразуется в Cи-шный, и очень просто использовать
Хорошая идея, записал в список :)
multiprocessing: Я что, какая-то шутка?
Привет, крутой видос как всегда. подскажи пожалуйста как подрубить визуальное автодоплнение в терминале?
Привет, это oh-my-zsh
@@zproger благодарю
Если в цикле будут другие операции, изменение скорости выполнения не будет в процентах это очевидно, оно так и останется примерно 5 сек
Мысль была в том, что если оставить такое количество итераций на действиях, которые потребляют больше ресурсов, то в итоге чем больше итераций мы сделаем, тем больше будет разница между этими циклами.
Когда изначально мы делали 1млн итераций, разница составляла несколько миллисекунд, на значении же в 100млн итераций, разница составила 6 секунд, в итоге тяжелые операции сделают скорость выполнения ниже, и это количество приведет к огромной разнице в циклах.
Здравствуйте, я подумал ролик к 1 апреля, что цикл for быстрее while. У вас манипуляция в коде, в цикле while у вас
Как можно сгенерировать данные для функции?
Тему не подскажешь?
Только подскажите, какова причина Вашего перехода с Линупс Манжаро на Линупс Минт?
Для видео всегда использовал минт)
ну видео бы назвать `как анализировать код на python’. потому как пересесть с цикла на цикл это так себе ускорение. здесь ни pypy, ни оптимизация через лямбды, ни numba, ни cython не упомянуты. но для начинающих, да, сойдет. кроме того кроме cprofiler не одинок в своем роде.
Как ты сделал такое меньше либо равно?
Это IDE так нарисовала :)
мне не нравится
Есть ещё py-spy
Благодарю, полезно
Ну не знаю навіщо це якщо чесно так можна замість циклів ітераторами працювати, можна код компілювати(статично і динамічно) хешировати, паралелити, деякі розрахунки через векторизацію проводити, викликати певні операції з різних бібліотек де краще все оптимізовано, але, як на мене, це не ті задачі які стоять перед пайтоном в кінці розвернуть все не сервері дай буде ок, а якщо не хвата швидкості тоді проще дещо переписати на том самом GO, а не паритися for це чи while
P.S. це суб'єктивна думка якогось чувака з нета
Не знаю как это по тематике подходит или не очень. Сними про нейросети там что то..
Есть пару идей на эту тему, сделаю видео обязательно
да итератор немного быстрее , но время выполнения кода внутри цикла будет одинаковым , и увеличение сложности кода внутри цикла не увеличит разрыв, но это не точно
Для python достаточно jit заиметь. И любые трепеты о скорости уйдут со временем.
Согласен, jit мощная штука
Боже мой... Скорость исполнения итерирования и вайла НЕ ЗАВИСИТ от того что в них исполняется.
Вообще, в большинстве случаев: грамотное использование numpy - ускоряет код уже довольно неплохо. Ну а сверху можно и numba и +- простые вещи, не требующие чего-то "лишнего" кроме numpy будут летать.
Жаль бинарный поиск невозможно отследить видимо это слишком быстро даже профайл не находит время ) 24 итерации максимум. А после переполнение памяти . даже используя цикл на 10000 итераций считается только время цикла
Он очень быстрый