🐸 Смотрим бенчмарки .NET 11 async рантайма Я и сам хотел пробенчмаркать, но тут намедни вышла статья про это же дело. Автор решил потестить новый рантайм асинк против .NET 10, и что мне отдельно понравилось: он ещё потестил .NET 11 с обычным, не рантаймовым асинком. Короче, вот что получилось интересного: Смотрите, вот у нас с вами есть корпоративные приложения, которые большинство из нас и делает. Как они строятся: вы приняли что-то в контроллере, отдали в сервисок, сервисок в другой сервисок, тот в репозиторий и так далее. Все это обычно (обычно) мы смазываем async/await. Давайте посмотрим, какой выигрыш мы тут получаем ⬇️ 🚀 Варинат 1: никто ничего не ждёт. Попали в кэш, всё вернулось сразу. В этом случае получаем выигрыш. Двадцать слоёв async подряд: на .NET 10 это 155 нс и 1512 байт, потому что раньше Task создавалась на каждый слой вызовов. С рантайм асинком 44 нс и 72 байта, и ОДИН Task на всю цепочку. В 3,5 раза быстрее и в 21 раз меньше памяти! И глубина асинхронных вызовов перестала вообще хоть что-то значить! Можете ебошить теперь async/await просто по-приколу! ❤️ Вариант 2: в котором мы идем в (жопу) базу. Такие сценарии при двадцати слояз и ожидании в самом низу стэка стали на 13% быстрее и жрут на 26% меньше памяти. В цифрах: 1862 нс против 2146 и 1472 байта против 1980. Рантайм переиспользует объекты продолжений и не сохраняет локальные переменные, которые не поменялись 🩳 Вариант 3: сразу ждем не переходя особо по цепочке (сразу в репозиторий к примеру мы пошли) Вот тут памяти уходит больше: 256 байт против 206, а если у метода есть переменные, которые переходят через await, то 288 против 216. Компилятор их больше в стейт-машину не выносит, но рантайму всё равно надо их где-то сохранить. Но по времени не хуже: на 17% быстрее или в пределах шума 🌊 Вариант 4: стримим данные через await foreach по IAsyncEnumerable. Тысяча элементов на 20% быстрее, 4786 нс против 6043! Стримеры порадуются! 📺 🐏 Сильвестр сЭталоунэ: Сравниваем с .NET 11 с обычным асинком. Почему это вообще важно? Первое время после переезда на 11 мы будем все жить как раз на таком варианте. Если кой-чего не сделаем. На цепочках из варианта 1, которые ходят в кэш и не ждут чтения из базы, он медленнее .NET 10 примерно на 30%: 18 нс против 13 на одном слое и 205 против 155 на двадцати. Почему, автор не знает. Если бы мы знали, но мы не знаем. То есть просто обновиться на .NET 11 и не включить рантайм асинк на таких цепочках может выйти в минус. Да я думаю оно и выйдет. Включается он одной строкой в csproj: Features со значением runtime-async=on. Это и есть то самое кой-чего. 🅰️ Что это значит для нас. Надо быстрее ждать новый вот этот вот рантайм и влкючать его, включать! ⚠️ Есть много оговорок по бенчмарку: это RC3, а в Preview 7 тесты с ожиданием были вчетверо медленнее. Мерили на одной машине (Apple M5 Pro, arm64, macOS). И это микробенчмарки: вместо похода в базу там Task.Yield, так что в живом запросе вся эта механика только малая часть времени. Ой, но кого это все вообще волнует! Это душно. Все будет заебца. Ну может не все. Или типа на пару процентов не так заебца. Это душно и скушно. Ждем, ждем, ждем. 😲 #csharp #dotnet #performance

🛠 Рантайм: что он делает для нашей программы В прошлый раз мы посмотрели, какие библиотеки подгружаются в процесс нашего Hello world. Давай теперь соберём вместе основные обязанности рантайма: с частью мы уже познакомились, разберём остальные👇 📚 Загружает код и типы Мы уже видели, как рантайм загружает нашу hello.dll и другие библиотеки, которые понадобились программе Рантайм загружает сборки с кодом и описаниями типов. По этим описаниям он определяет, как размещать объекты в памяти и как работать с их полями и методами. Типами здесь могут быть, например, классы нашей программы, или знакомый string ⚙️Готовит машинный код Эту часть мы тоже разобрали: рантайм решает, когда вызвать JIT, а тот переводит IL метода в машинный код процессора. Позже рантайм может заказать оптимизированную версию метода и переключить вызовы на неё 🧵 Управляет потоками Поток можно представить как исполнителя, который идёт по коду программы и выполняет команды одну за другой. В одной программе таких исполнителей может быть несколько: например, один формирует отчёт, а другой продолжает обрабатывать веб-запросы Потоки предоставляет операционная система, а рантайм позволяет работать с ними из C# через класс Thread. Кроме того, рантайм создаёт служебные потоки для собственных нужд Для выполнения множества заданий в .NET есть пул потоков, ThreadPool. Он распределяет работу между потоками и использует их повторно. При создании нового потока .NET обращается к ОС Пул регулирует количество своих потоков, но не управляет всеми потоками процесса. Например, основной поток, в котором начинается выполнение Main нашего Hello world, в пул не входит. 🧹 Управляет памятью объектов Для хранения объектов .NET использует управляемую кучу: так называется область памяти, которой управляет рантайм. А освобождением занятой объектами памяти занимается сборщик мусора, или GC (Garbage Collector) Например, в var hello = "Hello world" переменная hello хранит ссылку на строку: значение, по которому программа обращается к этому объекту. Ссылки могут храниться и внутри других объектов Во время сборки мусора GC определяет, до каких объектов программа ещё может добраться по таким ссылкам, в том числе через другие объекты. Память, занимаемую недоступными объектами, он может освободить для новых. Благодаря этому компоненту нам не приходится вручную освобождать память из-под каждого объекта 🚨 Помогает обрабатывать исключения Исключение сообщает о ситуации, которая прерывает обычное выполнение кода: например, когда программа пытается преобразовать строку "Hello" в число Рантайм ищет подходящий обработчик catch в текущем методе и в методах, которые его вызвали. Поэтому обработчик может находиться не там, где возникло исключение, а выше по цепочке вызовов 🔎 Позволяет заглянуть внутрь программы Рантайм предоставляет возможности для диагностики, в том числе поддерживает взаимодействие с отладчиком. Это позволяет нам приостанавливать программу, выполнять код по шагам, и смотреть значения переменных Другие диагностические инструменты помогают узнать, как часто происходят сборки мусора и сколько памяти занимают объекты, что полезно для оптимизаций 🅰️ Что запомнить 🟢 Рантайм загружает код, организует его JIT-компиляцию, помогает работать с потоками, управляет памятью объектов, участвует в обработке исключений, и предоставляет возможности для диагностики 🟢 Он обслуживает программу всё время её работы 🧑‍💻dp🥁 #dotnet #csharp #инженерныештучки #heavywednesday

Как устроены браузеры на Chromium 🧛 Короче, понудю еще про свой Meridian. Electron-версию пришлось оставить как я и писал выше: к ней были вопросы по безопасности (Node.js внутри браузера, лишние процессы, открытые порты) и гугл меня после каждого логина начинал харасить проверками всех двухфакторок и предупреждениями, что возможно я сдаю себя с потрохами мошенникам. Решил собирать браузер по-взрослому, из исходников Chromium. Как это устроено Берёшь Chromium, форкаешь и накладываешь свои патчи. Главное правило: чтобы форк не разъезжался с апстримом, весь свой код живёт в отдельной папке модулями, а в файлах Chromium остаются только маленькие хуки. Тогда ребейз на новую версию раз в 4 недели не превращается в ад. Почему раз в 4 недели? Потому что это частота с которой выходят секьюрити патчи хрома. Интерфейс — это веб-страницы на TypeScript внутри Chromium (экспериментальный WebUI-браузер, фича Webium), логика — сервисы на C++, а между ними mojo, внутренний IPC Chromium. Я вот не знал а оказывается браузер это целый набор микросервисов со своей шиной - как раз вот этой mojo. Почему в итоге Meridian будет безопасным Потому что по факту это будет тот же хром. Типа как оболочка для винампа. Риски Webium экспериментальный, Google может его дропнуть. Пока посмотрим, надеюсь, в случае чего перевайбкодить на что-то другое получится без боли. Сборка Под каждую платформу собирать придётся отдельно. Мак на маке, а Windows и Linux на моём виндовом ноуте: Windows нативно, Linux через WSL2. Подключу его как self-hosted runner к GitHub Actions. Нужно только докупить планку памяти: Chromium ест много. Никогда так не делал. Знаю что наши ребята мобильщики для iOS такое собирали. Интересно тоже будет попробовать. Ради интереса посмотрел сколько бы стоило собирать релизы на гитхабовских ранерах, получилось что-то типа 20-50 баксов за релиз. Что как-то дохуя. А можно на C#? Посмотрел из прикладного любопытства, можно ли чето прикрутить к любимому шарпику. Оказалось, что Avalonia + встроенный Chromium (CEF) — это по сути тот же Electron, только с .NET вместо Node. Твоё приложение становится хозяином, а Chromium — компонентом внутри, и все те же претензии к безопасности остаются. Короче если хочется сделать браузер, который не вызывает подозрений у серьезных сайтов, то путь один: брать Chromium и допиливать форк. А WebAssembly? Еще можно зайти в шарпик через Blazor WebAssembly в WebUI-страницах: WASM живёт в песочнице, как и TypeScript, так что с безопасностью всё ок. Но рантайм .NET грузится долговато, порядка сотни миллисекунд. То есть любая хреновинуа и финтиплюшка будет давать задержку. А сайдбар и ⌘T должны открываться мгновенно. Так что скорее экзотика, чем рабочий вариант. Нативно или веб? Arc, оказалось, полностью написан на Swift поверх Chromium, это самый «нативный» путь. Но на порт под Windows они потратили огромное количество времени. В меридиане я решил все же сделать UI на TypeScript который запускается везде одинаково и, как бонус, тратит заметно меньше токенов при работе с агентами. Так что кроссплатформенные подходы вроде веб-UI или React Native всё ещё очень даже полезны. А еще я чет так угораю с этого всего. В студенчестве помню писал всякие проги на Delphi. Если кто вообще помнит что это такое))) Короч там был компонент WebBrowser. И я помню что тогда меня прикалывала мысль, что можно на такой штуке запилить свой фаерфокс. Короче испытываю сейчас похожие ощущения азарта, хотя и код там не пишу 🙂