Тоже напишу про мой опыт - был я не самый опытный пользователь (года это 98-00) и нам продали Pentium 66 разогнанный до 100 (об это я узнал сильно позже). Были из-за этого постоянные проблемы с вылетами и зависаниями.
Так вот, на этом компе стабильно работала только Windows 95 и 98 - стабильно в том смысле, что не разваливалась после зависаний. Все остальные - OS/2 Warp, разные линуксы - либо не работали после установки, либо просто не могли установиться.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
Есть важный нюанс: планировщик операционной системы сам решает, когда выделить потокам время на выполнение. При этом GIL в CPython заставляет поток освобождать его примерно раз в 5 миллисекунд.
* For the longest time, the eval breaker check would happen
* frequently, every 5 or so times through the loop, regardless
* of what instruction ran last or what would run next. Then, in
* early 2021 (gh-18334, commit 4958f5d), we switched to checking
* the eval breaker less frequently, by hard-coding the check to
* specific places in the eval loop (e.g. certain instructions).
* The intent then was to check after returning from calls
* and on the back edges of loops.
*
* In addition to being more efficient, that approach keeps
* the eval loop from running arbitrary code between instructions
* that don't handle that well. (See gh-74174.)
*
* Currently, the eval breaker check happens on back edges in
* the control flow graph, which pretty much applies to all loops,
* and most calls.
* (See bytecodes.c for exact information.)
В плане реквестов в CPython довольно просто - это открытый проект, с открытой политикой, в массе своей поддерживается и развивается волонтерами, есть краткий гайд - Python Developer’s Guide .
В этом плане любой может прийти и создать реквест. Только чтобы изменения попали в "мастер" ветку, нужно чтобы реквест прошел ревью и одобрение со стороны code-owners. В моем случае Нил забраковал решение и сделал свое. Нил если что занимался GC в питоне еще в начале 00, так что тут никаких обид :)
Чтобы разобраться - нужно просто сидеть и разбираться. Здесь тоже нет ничего необычного - нужно желание и время. Ну и мне в определенной степени повезло, что проблема была связана с той подсистемой с которой я разбирался ранее.
Неожиданно, но приятно! Спасибо!
Тоже напишу про мой опыт - был я не самый опытный пользователь (года это 98-00) и нам продали Pentium 66 разогнанный до 100 (об это я узнал сильно позже). Были из-за этого постоянные проблемы с вылетами и зависаниями.
Так вот, на этом компе стабильно работала только Windows 95 и 98 - стабильно в том смысле, что не разваливалась после зависаний. Все остальные - OS/2 Warp, разные линуксы - либо не работали после установки, либо просто не могли установиться.
Хорошее дело, отличный разбор!
За ложку дегтя спасибо! Столкнулся с этим, но не разобрался в причинах.
Очень интересно, спасибо!
Я понимаю разницу. Автор поменял название статьи - в оригинале было - как уменьшить кодовую базу.
В текущем названии вопросов нет.
Статья интересная (без шуток) - спасибо!
Но все таки - как уменьшить кодовую базу? Потому что, например, ваш пример с дешаблонизацией кодовую базу только увеличит.
Спасибо что и иллюстрации поправили.
неопределенное
Ну и качество иллюстраций в статье просто потрясающее.
Я не ставлю под сомнение вашу честность :)
Просто совершенно не очевидно стоит ли игра свеч и масштабируется ли ваш опыт за пределы вашего проекта.
Не очень понятно, как уменьшение размера на 0.06% так сильно влияет на скорость загрузки. У вас условно была библиотека 300Мб и осталась примерно столько же. Так все таки - за счет чего такой прирост производительности?
Это напоминание о моей глупости - я думал я понимаю как работает GIL, а оказалось не понимаю. Будет повод разобраться глубже.
Спасибо!
Спасибо!
Спасибо организаторам за крутую конфу, а коллегам за очень интересные доклады! Узнал много нового!
Спасибо, было интересно!
Хотел бы добавить комментарий - не стоит забывать, что в случае
gc.set_debug(gc.DEBUG_LEAK)весь мусор уедет вgc.garbageи там и останется.Презентация от автора про
tail-calling interpreterhttps://docs.google.com/presentation/d/10oznjsxU45TzdwCrtLoK9cm3xcsavIYh2vlZ2RkWkhU/edit?slide=id.g344929f9bd2_1_6#slide=id.g344929f9bd2_1_6В массе своей все равно энтузиастами. Это вот такая объективная реальность данная нам в ощущениях.
Ну я мастер формулировок, простите если запутал.
В плане реквестов в CPython довольно просто - это открытый проект, с открытой политикой, в массе своей поддерживается и развивается волонтерами, есть краткий гайд - Python Developer’s Guide .
В этом плане любой может прийти и создать реквест. Только чтобы изменения попали в "мастер" ветку, нужно чтобы реквест прошел ревью и одобрение со стороны code-owners. В моем случае Нил забраковал решение и сделал свое. Нил если что занимался GC в питоне еще в начале 00, так что тут никаких обид :)
Чтобы разобраться - нужно просто сидеть и разбираться. Здесь тоже нет ничего необычного - нужно желание и время. Ну и мне в определенной степени повезло, что проблема была связана с той подсистемой с которой я разбирался ранее.