Comments 13
Native AOT + ReadyToRun -- не очень понятно то имеется ввиду под этим.
Это я ради эксперимента попробовал одновременно использовать оба подхода к компиляции в машинный код.
Вообще, по идее должен был быть конфликт. Потому что Native AOT это полная компиляция решения в машинный код, а ReadyToRun только частичная. Но судя по тому что приложение запустилось и его объем увеличился, можно сказать что эксперимент удался)
Но публиковать приложение, собранное таким образом, конечно же не стоит)
Их нельзя использовать вместе никак, это два разных рантайма. У вас на выбор 4 опции:
NativeAOT
JIT + R2R (обычно все базовые библиотеки в R2R идут), при этом весь R2R код (если он горячий) по итогу все равно пере-компилируется джитом в Tier1
JIT-only (если насильно отключить R2R).
R2R-only, но тут практически нереально добиться того чтобы джит не вызывался
Ещё есть интерпретатор новый.
Нда, с дотнетом прямо совсем с размерами печаль. Самый толстый модбас сканер в мире получился =)
Согласен :)
И пока что не вижу путей как ещё уменьшить размер приложения. Native AOT был последней надеждой.
Помню, как то пытался перенести часть функционала на Qt. Размер приложения уменьшился. Но я как разработчик не был в восторге при использовании этого фреймворка. Пока что мне больше нравится связка C# и xaml разметки.
Вы можете пойти другим путем:
- реализовать сервисную часть на native aot и запускать ее, например, как службу windows или предоставлять как общую библиотеку
- реализовать отдельно ui-часть
если обеспечить совместимость на уровне контракта, то вы сможете обновлять лишь нужную часть, а не требовать перекачки всего приложения. к тому же станет очень очевидным, где лежит самая тяжелая часть приложения.
p.s. всё-таки, на мой взгляд, native aot - это больше про оптимизации, когда вы решили работать напрямую с памятью, указателями и т.п., но не желаете менять язык, и в большинстве проектов в этом нет необходимости - это нецелесообразно.
а чтобы приложение от долгого старта не казалось зависшим - есть отдельные приемы для визуализации этого процесса.
Самая большая часть приложения - это .NET Runtime)) Я публикую приложение автономным, чтобы не зависеть от наличия рантайма на машине пользователя.
В другом проекте я пробовал разделять приложение на службу и UI часть. И ко всему прочему добавились ещё и проблемы с отладкой взаимодействия этих двух компонентов. Не забываем ещё про отладку и возможные ньюансы на разных ОС. Поэтому не вижу в этом смысла.
Также если использовать Native AOT только в одном из компонентов приложения, то это не решит проблем описанных в статье.
Но я в целом соглашусь с тем, что вы написали в постскриптуме. А в моем случае, эксперимент с оптимизациями не удался.
В .net 9 пофиксили ложное срабатывание антивируса. До .net 9 помогало перемещение .managed в .text(вроде), на гите dotnet можно найти информацию по этому поводу.
К сожалению, у меня на ПК с Windows 11 были ложные срабатывания. Собирал как раз на .NET 9. Подожду релиз .NET 10. Надеюсь, там это исправят.
CoreBus: Часть 5 — попытка использования Native AOT