Блог*

#rust Add panic_unreachable_unchecked feature flag to the standard library

This is similar to panic_immediate_abort except that all panics are considered immediate UB and can therefore be optimized away as unreachable by the compiler. This has been tested on regalloc3 where it resulted in a 10% speedup compared to using a normal standard library, mainly due to the elimination of bounds checks. While it may seem that this feature merely to satisfy those with a reckless thirst for performance at any cost, it is also useful for saner heads as a profiling tool to investigate the impact of unnecessary safety check and find places where unsafe code could be used to avoid them.

#этотравля

В СМЫСЛЕ УЖЕ АПРЕЛЬ

Рисунок на скорую руку в баре Видимо, #моё?

Несколько недель назад на GitHub, наконец-то, появилась возможность отсоединить свои публичные форки без потери всех метаданных (issues, stars, releases, etc) репозитория. Работает примерно так же, как и на Gitlab — нажимаешь на кнопку "отсоединить" в настройках репозитория, и все готово. Единственное отличие, что если репозиторий форка слишком большой (1 GB+ или имеет другие дочерние форки), то для отсоединения все-таки нужно будет написать в саппорт и объяснить причину отсоединения. Я давно хотел преобразовать один из своих форков в самостоятельный репозиторий, поэтому не мог пройти мимо и не проверить перенос через саппорт лично. На удивление, мне довольно быстренько ответили и отсоединили форк без лишних вопросов. Теперь репозиторий отображается в поиске на GitHub, а в моем профиле стала показываться даже вся старая статистика коммитов из репозитория 🐈‍⬛

Админ @test_channel_grammers, не пересылай все посты Блог*а подряд, пожалуйста

Что ж Номинально мне нужно ждать ещё четыре часа, но календарно — С днём рождения меня, с днём рождения меня. 27 лет. Пора в клуб.

Почему надо обновлять не только Chromium. Прямо вслед за новостью об уязвимости в Chrome и Chromium, свой браузер Firefox пропатчила Mozilla. Да, Хромиума нет, а уязвимость, получается, есть (была), и она находилась в логике взаимодействия песочницы с ОС, которая у разных браузеров имеет (имела) схожую ошибку. Напомню, мы недавно обнаружили дыру в Chrome и лежащем в его основе Chromium ( который также используется в Яндекс.Браузере, MS Edge и т.д.). Уязвимость использовали в реальных атаках на цели в России, судя по всему, достаточно продвинутые хакеры. В общем, обновляйте и Firefox тоже.

"Пусть всё пройдёт, как по маслу" А ничего, что масло вообще-то довольно плохая смазка?

#prog #article #amazingopensource Jujutsu (jj) — система контроля версий, которая концептуально проще git и при этом мощнее. Неплохой (но местами устаревший) обзор Jujutsu — jj init — сделал Chris Krycho. Также есть пока что неполный туториал от Стива Клабника, который тот написал главным образом для того, чтобы самому лучше разобраться с Jujutsu. Этот туториал даже рекомендуется в официальной документации. Сразу скажу: jj работает поверх git, так что её можно поставить поверх имеющегося репозитория и потом без проблем удалить. (у jujutsu также есть нативный бекенд, но он пока не готов и не рекомендуется к использованию) Что же такого примечательного в этой CVS? Попробую объяснить (но лучше почитайте по ссылкам, чесслово, там хорошо описано). В обоих описаниях бросается в глаза наличие операций, описанных в Where are my Git UI features from the future?. Как и git, jj идейно работает на снапшотах файловой системы. В отличие от git, коммиты в jj напоминают объекты в ООП: они мутабельны и имеют идентичность, которая остаётся постоянной при изменениях самих коммитов — да, в том числе при ребейзах. В отличие от git, в jj нет отдельной стадии стейджинга изменений и фиксации коммита. Более того, jj вообще не использует индекс — jj отслеживает изменения файлов и автоматически записывает их в текущий коммит (не волнуйтесь, есть средства для разбиения изменений). Для того, чтобы закончить с текущим коммитом, достаточно вызвать jj new для создания нового коммита, который отпочковывается от текущего. Описание для этого вводить необязательно — его можно добавить задним числом. Недостаток этого решения — большинство инструментов поверх git предполагают использование индекса и потому не очень хорошо стыкуются с jj. Как я уже сказал, описание коммитов можно добавлять и менять в любой момент, вне зависимости от того, какой коммит текущий. Ветки в jj анонимны, и это взрывает мозг тем, кто учился CVS на git (мне в том числе). Именованные ветки из git доступны в jj под именем bookmarks, и, в отличие от git, эти указатели не смещаются автоматически при добавлении дочерних коммитов — для этого нужно вызвать отдельную команду. Это выглядит неудобным, но по факту это даёт некоторые преимущества. Одно из них — нет нужды придумывать имя для каждого логического изменения. Он требуется лишь тогда, как нужно расшарить изменения с другими. Другое — если в локальной копии слишком много изменений и стало понятно, что они идут куда-то не туда, можно просто откатиться до ветки (при условии, что локально её не двигали) и просто дропнуть коммиты после неё. Коммиты можно свободно двигать в истории. В отличие от git rebase, имена коммитов после этого не меняются. Ребейз и мердж в jj всегда успешно завершаются. Это не означает, что конфликты невозможны. Но в jj конфликты являются первоклассными значениями. Это позволяет слить несколько последовательностей коммитов в одну и разобраться с конфликтами позднее (и потом, возможно, слить разрешения конфликтов с мердж-коммитами). Команда jj undo отменяет действие предыдущей команды. Дико не хватает этого в git. Почти все команды jj позволяют указывать коммиты, на которых они действуют (и используют текущий коммит, если этот аргумент не указан). Более того, это может быть несколько коммитов — или revset в терминологии jj. Задавать revset-ы можно при помощи отдельного достаточно мощного языка выражений. В качестве побочного эффекта это означает, что, помимо всего прочего, в jj можно сделать мердж больше двух веток сразу. Например, для того, чтобы просмотреть все локальные "ветки" (коммиты без дочерних коммитов), можно использовать jj log -r 'heads(all())'. all() возвращает все коммиты в репе, а heads извлекает из набора коммитов те, у которых нет дочерних. Если этого недостаточно и нужно добавить контекста — скажем, по два родительских коммита — можно использовать jj log -r 'ancestors(heads(all()), 2)'. (это лишь мой пример, по умолчанию jj log использует несколько более полезный формат)

Принесла вам чудесную серию рисунков — Franciszka Themerson, Science and Technology: 1. radio-astronomy 2. distillery 3. high voltage и, внезапно 4. the tea break (британские ученые такие британские, даже если они польские художницы, перебравшиеся в Лондон в сороковом)

🧠 Как 3 вечера анализа и оптимизаций дали минус 1 CPU и +40% к скорости ответов API 👀 Всё началось с того, что я случайно (ну как случайно, проблема была всегда, просто я первый задался вопросом - "почему?") заметил, что один Python-сервис на staging потребляет до 2.5 CPU. Для сравнения — весь namespace потребляет около 6 CPU. То есть один сервис ест почти половину ресурсов. И это при том, что это не какой-то нагруженные сервис, это синхронный API-сервис, да еще и без нагрузки, это же staging. Стало интересно — а что там внутри вообще так жрёт? 📦 Запустил профайлинг CPU через Pyroscope и… понеслось. UI у Pyroscope меня не устроил — флеймграфы красивые, но неудобные для глубокого анализа. 📥 Поэтому я выгрузил дамп как pprof файл и открыл его через go tool pprof. Так мне удобнее, быстрее и информативнее. 📊 Профилирование показало несколько важных узких мест: 🧱 Проблема №1: конвертация данных из MySQL Самое "жирное" место — conversion.py → MySQLConverter.row_to_python. Это код, который конвертирует строки из БД в Python-объекты на каждый запрос. Наиболее затратные конвертации: - _DECIMAL_to_python - _INT_to_python - _JSON_to_python - _DATETIME_to_python - _STRING_to_python ✅ Решение: 📌 Использовал C extension у mysql-connector-python Официальная документация: https://dev.mysql.com/doc/connector-python/en/connector-python-cext.html 📉 Результат: - Минус 1 CPU - До +40% ускорение некоторых endpoint’ов 🧠 Проблема №2: неэффективный Python-код Пример: функция change_type, которая: - делает кучу проверок в логике - использует неэффективные структуры данных, например, list для поиска вместо set / dict - обрабатывает сразу множество возможных вариантов логики, в зависимости от входных данных ✅ Решение: 📌 Переписал участок без изменения бизнес-логики: - заменил структуры данных - добавил ранние выходы - убрал дублирующиеся проверки 📌 Cognitive complexity снизилась, временная сложность — тоже. Производительность выросла. ⚠️ Проблема №3: код, который не нужен, но работает Профайлинг показал, что куча ресурсов уходит на код, который вообще не должен уже как год использоваться. Но код активно выполняется. WTF!? 🤷‍♂️ Функции вызываются, результат — пустой, но код исполняется. Причём часто и тяжело. ✅ Решение: 📌 Удалил мёртвый код, обновил импорты, подчистил зависимости. 📌 Поднял вопрос о полной деактивации этого кода и мы таки это сделали — ресурсы можно использовать лучше. 🐘 Проблема №4: Импорты. Много. Дорого. Во время анализа я наткнулся на ещё одну тихую, но дорогую проблему — огромные ресурсы уходят на фазу импорта модулей в Python. Конкретно — на _find_and_load, часть механизма импорта, который занимается поиском, загрузкой и инициализацией модулей. 📌 Почему это важно? - Импорты выполняются на каждый старт сервиса. - Чем жирнее и зависимее ваши модули, тем дольше и тяжелее проходит импорт. - Это не всегда очевидно, но можно видеть в профайлинге: _find_and_load, _find_and_load_unlocked, _load_unlocked – вот это всё. 📊 У нас в сервисе модулей реально много. Многое из них – просто "свалены в кучу", где-то грузятся тяжёлые зависимости. Да и сложная структура проекта вынуждает иметь большое количество импортов. И, как итог, CPU тратится на то, что можно было бы стремиться избежать. ✅ Что с этим делать: - Разделять модули по функциональности. - Отложенные импорты (lazy import) – практика может применяться (но есть нюансы), если модуль нужен только в конкретной функции. - Минимизировать зависимости и импорт только того, что действительно нужно. - Следить за импортами в __init__.py — именно они могут тянуть за собой пол кодовой базы. Следующий шаг: memory профайлинг. Pyroscope в нашей инфрастуктуре такое не умеет и нужно приседать, но надеюсь дойдут руки и до RAM.

#ml #suckassstory

AI всех заменит или удалит

#prog #rust #article How to speed up the Rust compiler in March 2025