Лучшие способы Ускорить и Оптимизировать Python код

[@DanisNone]

lru_cache не удаляет все значения. При достижение maxsize он удаляет значение который использовалось наименьшее количество раз

[@ДжетЛи-ы5т]

Не знаю почему, но это для меня интереснее парсера. Продолжай в том же направлении. Однозначно лайк!

[@zproger]

спасибо, продолжаю :)

[@m0Ray79]

Ну как бы кэширование я не назвал бы ускорением и оптимизацией именно кода. Ну да, такая технология ускоряет выполнение и уменьшает нагрузку, но блин... А вот что я назвал бы оптимизацией - так это применение Cython. И я пытаюсь нести эту технологию в массы, в том числе через ютубчик.

[@johannex.]

А что насчёт numba?

[@firstandlast4435]

На английском, дружище... На нём же итак тонна материала написана.

[@ЛисаВОгне]

Про доп оптимизации: 0. Продумывание кода. 1. Использование правильных типов данных 2. Интеграция других языков программирования (С, к примеру) 3. numpy 4. numba 5. multiprocessing 6. Алгоритмы 6а. Выбор алгоритмов под задачи У тебя классная подача, и было бы интересно с данной подачей узнать про более сложные темы (Виды кешей, использование рекурсии в деревьях, сами деревья)

[@codingjerk]

Этот коммент лучше чем ролик)

[@mcomponent]

не совсем соглашусь с вашим ответом. Интеграция других языков вещь спорная, она нужна далеко не всегда и далеко не всегда даёт прирост производительности. Чаще бывает так, что внутренняя работа с dl'ами занимает больше времени. А ещё это очень сильно снижает стабильность кода и безопасность его работы. Numba - решение тоже спорное. Оно, как никак, частично убивает всю суть питона, а именно то, что для запуска любого софта достаточно стандартного тулсета Python и все платформозависимые вещи исполняются в основном за сценой.

[@kirbulich]

Использовать mojo

[@blackcatdevel0per]

Ещё асинхронка))

[@tzn9597]

А если cython использовать?

[@grigoriperelman9063]

Привет, очень интересно, а у тебя есть опыт разработки каких-то проектов?

[@bezik572]

можно было бы рассмотреть использование динамических библиотек через ctypes. Помимо того, что это банально ускоряет выполнение cpu задач, так еще и модно использовать сишный многопоток, который хорошо ускоряет выполнение cup задач. Сразу скажу - для библиотек на C++ лучше использовать компилятор clang++ (у меня только он нормально работает. Компиляция с флагами -fPIC (динамическая аллокация) -shared main.cpp -std=c++17(стандарт) -Wall (вкл варнинг))

[@afutik]

Очень благодарен за такие видео

[@zproger]

Спасибо!

[@ИванКлопов-и8о]

Какая ОС используется и как так красиво настроить её?)

[@michaeln3085]

Вот так вот. Очень бесит забеги туда сюда в повествовании, никакой системы, рваный ритм сбивает текущий контекст и становиться не понятно. Подростковая речь.

[@СергейЧ-ь2к]

Ребят, а увеличится ли скорость если весь код, вместе с базой данных загрузить прямо в оперативную память и от туда запускать?

[@RockstarAlexander]

Четко 🎉

[@zproger]

Спасибо

[@RoVi-nn3ks]

А как называется этот Линукс distro?

[@alexaeb5908]

Привет, смотрю твои видео и оч прикольные и нахожу много полезного для себя! Спасибо за работу друг! Но мне кажеться тут схитрил и не совсем равномерное сравнение - это логично, когда "считать готовый результат" будет намного быстрее "вычислить его" - тем более когда это нужно сделать xN раз подряд. Методология абсолютно справедлива, как пример можно принести хэш таблицы перебора ключей в гидре (кто игрался кали линуксом поймут) - один раз создал хэш таблицы паролей и брути себе на здоровье. Всем удачи )

[@dimk7983]

Когда двойку на единицу менял, специально кавычки убрал?

[@OnlyElf]

Добрый вечер, спасибо за видео, но вы ошиблись. Кэш работает по принципе FIFO. Т.е. если кол-во уникальных запросов превышает параметр maxsize, то это не обнуляет весь кэш, а начинает убирать из него самые старые запросы, добавляя в конец "очереди" кэша новые.

[@zproger]

Спасибо за ответ, сейчас потестирую этот момент, вот только немного странно что при 3х элементах кэша, ничего не сохраняется, хотя maxsize=2.

[@miroslavn1]

@@zproger Проверять меняя maxsize 2 на 1 некорректно, если проверять по очереди 2 значения. Но можно сделать maxsize=2 и проверять по очереди 3 значения, но в обратном порядке. В этом случае, в кэше будет 2-е и 3-е значение, а первое будет потеряно.

[@Alsurnov]

Лучше Redis подключить. Например так: cache = redis.StrictRedis(decode_responses=True). Хоть это и не из стандартной библиотеки но так намного лучше, плюс в Redis вы легко зададите время хранения, например cache.set('info', '123434', 70), где 70 это время в секундах хранения значения в Redis, через указанное время кэш удалится сам.

[@Mr_AnKei]

Вот это очень помогло, огромное спасибо ZProger[IT].

[@Novice2213]

Для lru_cache можно передать None при декорировании рекурсивных функций. В таком случае будет тоже очень быстро работать, правда будет вызываться исключение, при использовании списков, словарей и т.д. как аргументов, но с числами работает хорошо

[@demg7738]

Так lru_cache уже давно многие знают, даже в курсах для начинающий по-моему видал, но это не точно. Особенно хорошо работает в плане вычисления каких-то значений с комбинацией констант и параметрами из настроек сервиса - вроде и хардкода нет, но и кэшируется всё что нужно один раз и далее работаем почти как с простым обращением к переменной. Ну или если много повторяющихся значений, например в показаниях какого-либо измерения.

[@Biolog3000]

Что такое @memory? Можете ,пожалуйста, объяснить.

[@zproger]

Декоратор. О декораторах есть видео на канале

[@programm_ing9097]

Получается с рандомом это не будет работать?

[@zproger]

будет, в телеграмм написал мини-статью об этом

[@freestreet_official]

Расскажи про ускорения asyncio кода, пишу сервер игровой...на 500+ онлайне уже даже asyncio не справляется..

[@mcomponent]

потому, что такие проекты не разрабатывают на Python. Игры и всё близкое к ним относится к сфере realtime, а Python в ней не силён. Лучше используйте C/C++, так будет и по памяти лучше, и по скорости разработки, и по скорости работы, и по простоте конечного кода.

[@stspartak]

Даешь видео про декораторы!

[@zproger]

😉😉

[@marc_timeed4355]

я не знаю рассматривал ли ты numba или taihi но и то и то это JIT и соответственно нереально ускоряют прогу. Я на их основе ускорил свой рейтрейсинг и получил вместо старых 8 ФПС новые нереальные 300. Единственный минус это то, что этот способ немного привередлив и мне пришлось полностью рефакторить код

[@non5309]

автор специально напрашивается на комментарии, т.к. знает что его сейчас будут поправлять что это не баг а задокументированная работа декоратора, где если макс_сайз 1 то это перезапись с сохранением последнего а не первого.

[@zproger]

Мне показалось странным, что это также работает при maxsize 2 и 3. Возможно найду время на более глубокие тесты и скину их результаты в телеграмм

[@AlexRootx]

лайк в поддержку канала!!!

[@zproger]

Благодарю!

[@lgotindev6712]

0_o Изобретения кеша? Вау) Redis, Memcache курят в сторонке) Ну, а если серьёзно, для новичков очень хорошее объяснение, но лучше использовать Redis и подобные решения для кеширования всё же.

[@Sultan69996]

Можно ли создать программу чтобы при наведении фотокамеру на монитор программа программирования поняла какой код написан, что оно делает, показывала ошибку и тд. Да можно скопировать текст передать на другой комп и тд. Но зачем если можно обойти эту систему. К примеру мы не хотим заражать свой гаджет разными вирусами и тд через юсб провод и тд. Как то так. Это защита гаджета от вирусов и тд ...... Тупо я знаю но все же. Благодарю за ответы

[@НеопознанныйБобр]

Херню написал какую то, копируй код и вставляй в chatgpt, он тебе все расскажет

[@nickolayfetlistov4416]

Не совсем, в конце то не баг, оно скидывает значение так как происходит переполнение буфера. На оф. документации питона сказано что этот метод работает вообще по актуальности, как новостной портал, который кеширует новости которые люди смотрят, если люди перестанут их смотреть он удалит их из памяти, и в этом случае также, вы можете попробовать пример с двумя значениями и кинуть туда третье, в конце там окажусь последних 2 использованных, то есть, например, 30 20 30 30 20 400 400 20, в кеше останутся 20 и 400 а 30 уйдут так как использовалось перед добавлением нового значения (400) использовалось 20. А по поводу подводки и говорить что никто на табчике жту тему не поднимал это не правильно) Заруб туберы точно когда-то вроде поднимали

[@zproger]

Спасибо за развернутый комментарий, было полезно.

[@ei9896]

Я подобное делал на PHP для чтения базы данных для карты, потому что сервер тяжело передавал данные из БД, а затем пользователю. Кэш был в файле. Всегда считывал данные в кэш при необходимости, но предварительно проверял кол-во строк из таблицы, и если оно изменилось , то кэш обновлялся, нет просто проходил мимо. И затем всегда выгружается кэш... скорость работы сайта выросла весьма существенно

[@captain_t0rch688]

Ждём видео про циклы

[@zproger]

=)

[@inferens]

Давай тогда уж видео про типизацию

[@FXUNDPLXGG]

Ждём видео про print

[@LiftBuff]

Странно, у меня с кэшированием через shelve c 30 проходами время чтения с файла 0,2 сек, откуда у автора такие дикие цифры в 2 сек?)) И без functools, если сделать кэш на основе обычного словаря , то время доступа так же в микросекундах. Ну а wraps нужен чтобы можно было получать документацию функции, так как иначе, с простыми декораторами вместо доков функции мы получим доки функции-обертки, а вместо имени - имя обертки. И еще насчет shelve - это все же лучший выбор для сериализации огромных чисел, так как на json действуют ограничения текстовых объектов

[@ИгорьЧерпалюк]

Помоему все норм. видимо кеш просто перезаписывается, если ему не хватает места. Надо было проверить три записи на maxsize = 2 уверен, что одна запись выполнилась бы быстро.

[@Shprotec]

Способы оптимизировать python: Шаг первый - изучаем c++ ...

[@alexches1954]

Я ускорял код python с использованием f2py (fortran) + openmp (для параллельного счёта с общей памятью).

[@zproger]

это что-то новенькое, спасибо

[@alexches1954]

@@zproger этот подход больше для научных вычислений подойдёт. Но в целом фортран очень лёгкий язык (в плане синтаксиса) и для математических операций подойдёт на ура (вроде как самый быстрый из компилируемых языков), но он точно не подойдёт для работы с текстом или для написания интерфейса. А openmp работает и с с/с++.

[@user-cy2gr8uc8p]

Хотелось бы добавить, что кешировать нужно только ЧИСТЫЕ функции!!!

[@mak32]

Попытался записать число в файл, там ошибка (4300 что-то там) сбросил через sys.set_int_max_str_digits(0). Но запись всё равно гипер медленная. Понимаю - это уже не числа.

[@mak32]

Ещё через такое возведение в степень Python в силах сделать только 35 циклов... А потом попробовал все это записывать в файл и со вчера до сегодня до сих пор записывает... Запись происходит каждого числа в файл txt предварительно число через str конвертирует

[@super_man-ArtOfWar3]

Попробуй записать в txt файл вот это int("10"*10**11, 36) Там число вроде в гигабайтах измеряется )))

[@raymond4193]

Иногда смотришь видео и удивляешься, задаешься вопросом, как и где ты берешь эту информацию?

[@super_man-ArtOfWar3]

Есть такое слово "эксперемент"

[@Иван-ь4ж5о]

Голова всегда пыхтит от пониманий вложенных функций, декораторов и таких вот замыканий

[@k3l3vr444]

Автор так умён, придумал кеш! А потом нашёл ошибку в станартной библиотеке в том, что она рабтает не так, как он думал А если без шуток, то вот что происходит при переполнении лру_кеша: Empty the oldest link and make it the new root. Keep a reference to the old key and old result to prevent their ref counts from going to zero during the update. That will prevent potentially arbitrary object clean-up code (i.e. __del__) from running while we're still adjusting the links.

[@АлександрМалахов-у9й]

Во первых lru_cache не очищает весь кэш, открывай дебагер и проверяй))) Там остаются последние значения. А вот что ты явно не сказал, это то что lru_cache запоминает исключения. И если функция однажды упала, например доступ к API вернул 500, то он закэширует ошибку 500, и больше не будет пытаться стучать в сервис)))

[@proofofconcept5272]

Это не повышение производительности, а кэширование. Бездумное использование замедлит программу, инструменты используются исходя из задачи.

[@Blecord]

в итоге ни cache ни lru_cache не сохраняют данные при перезапуске. А как же его вместе собрать то? Пойду кумекать над химерой:) Спасибо за контент, очень крутые видео и уроки делаешь!

[@nikolay1944]

Подключить Redis

[@Didar.Kussain]

👍

[@zproger]

Спасибо

[@qwerty0xD52]

Давай видео про pywin32 и ctypes

[@ekuulanbekov1557]

Решаю алгосики на питончике. И недавно заметил что пример; расширение строки my_str: str, mu_str += ‘a’ медленнее чем my_str.append(), ‘’.join(my_str()). И как я понял += работает почти за квадрат.

[@mcomponent]

Не могли бы вы чуть-чуть детальнее разъяснить вашу ситуацию? У str нету append, возможно вы преобразовали его в list? И, что вы подразумеваете под вызовом my_str() в методе с join? Можете рассказать, как вы проводили бенчмарки? Я, к сожалению, не смог повторить ваши результаты.

[@blackcatdevel0per]

Естественно, списки ведь один из замых оптимизированных типов данных python (но ОЗУ жрёт больше, чем однотипные массивы C)

[@IT_psychopath]

тема полностью не раскрыта. я пока не понял чем оно мне поможет и зачем этот костыль вообще надо.. в python можно написать код в пару строк и он реально обгонит в 10 раз С++. да, такой прикол есть на хабре, если по рыться в комментах показывали такие реализации. это и есть оптимизации. но там нет магии, там Си используется но более оптимизированный и сложный. для быстрого выполнения есть модульность! python компилирует код!!! да, у его есть такая фича.)) он компилирует часто используемые функции и модули. хотите быстро, используйте компиляцию модулей. если вам надо скорость в вычислениях, есть numpy! не надо строить велосипед чтоб потом отстрелить себе ногу. надо быстрые переборы есть next! главное пишите на python так как надо писать на python а не как вы писали на С++, java, js... и все будет хорошо.)) python медленный пока что только при работе с GPU. в остальном если на нем писать правильно, он не уступает остальным яп. тому же java и тд.. понятно что С++ обгонит, но С++ компилится в ассемблер! и если вам надо С++ а вы пишите на python, то явно с вами что-то не так.🤣 у них разные задачи и там где надо С++, пишите на С++ просто.)))

[@Lines115]

Ты это с всего даркнета берешь??? Изменено: NumBa (знают все), taichi

[@voidptr_t]

Если тебе нужен быстрый код, ты не пишешь на питоне

[@zproger]

Ну смотря что подразумевается под быстрым, с ровными руками и Python можно сделать достаточно быстрым, чтобы покрывал большинство тасков.

[@voidptr_t]

@@zproger именно поэтому все микросервисы на питоне запускают в значительно большем кол-ве инстансов)

[@Biolog3000]

Поскорейбы тысяча лайков люди набрали.

[@zproger]

Согласен :)

[@skiffpublic4753]

Некорректное название ролика. Вся суть ролика: используйте кеш если вам надо делать возвращать результаты, которые долго вычисляются. Непосредственного ускорения вычислений нет.

[@damirasanov8993]

второй :)

[@zproger]

я первый =)

[@ПётрГригорьев-т1ь]

быстрая непонятная каша. Спасибо.

[@m-a-khozin]

Ну поучи немножко язык. Прежде чем видосики писать. LRU-cache запоминает ПОСЛЕДНИЕ использованные аргументы. Он не сбрасывает кэш при переполнении, а ВЫТЕСНЯЕТ. Да, именно так работает этот паттерн.

[@ironaddicts]

And you get cache poisoned

[@Руслан-п5в1ж]

Жесть так тороторить и прыгать по коду... уловить мысль совсем не просто с такой подачей👎

[@Sultan69996]

Я 105 ))))). 105 ком МЕНТ арий мой. Хахаха )))))

[@eurodoo]

кликбейтный заголовок, по сути просто кеш, причем кривой, дизлайк

[@SitVey]

ZProger, а ты случайно не патриот России? Или ник так совпал неудачно?

[@zproger]

нику 3 года уже, а то и больше

[@Player-og6br]

*удачно )

[@Ramzes646]

У тебя буква V заглавная в нике. На твой счет точно все ясно (по твоей логике)

[@lzrdblzzrd]

@@Player-og6br неудачно

[@Hezaki]

Ну и шиза конечно...

[@НикитаМакаров-б5п]

Самый лучший способ ускорить python, это забросить всё и перейти на С-подобные языки программирования

[@zproger]

:D

[@super_man-ArtOfWar3]

Самый лучший способ ускорить пайтон это сделать свой пайтон )))

[@dalerkhakimov5449]

LRU cache - Least Recently Used. It chops the oldest objects inside and when you give it maxsize 1 and then ask for 28 it writes it there, but when you ask for 27 it deletes 28 so that you have to count again and again. Сорри за мой англ. русской раскладки нет думал зае*сь все это писать. А так контент у тебя супер!!!

[@CrazyElf1971]

Ну да, казалось бы первым делом автору видео нужно было хоть посмотреть, что такое LRU, не просто так же эти буквы написаны ) Хотя проверять всё самому экспериментально тоже хороший подход, я сам так часто делаю )