Aspnetcore: Компиляция AoT

Следить за статусом моно-васма

Вы знаете проблему, по которой мы можем отслеживать прогресс в этом вопросе?

Текущий режим переводчика очень медленный.
https://dotnetfiddle.net/JUpsRT

.NET 300 мс
WASM: 13155 мс

Да, мы думаем, что это больше результат того, что еще ничего не оптимизировано, чем указание на то, что мы должны перейти на AoT на данном этапе, но мы узнаем больше по мере развития интерпретатора IL и поддержки AoT.

@ danroth27 Насколько я могу судить, разница в производительности между интерпретатором Mono IL и текущей версией mono.wasm составляет примерно 5-10 раз. В целом mono.wasm примерно в 50–80 раз, а интерпретатор IL примерно в 10 раз медленнее, чем собственное консольное приложение .NET Core.

Таким образом, в настоящее время интерпретатор в целом все еще не очень быстр, а WebAssembly добавляет к этому еще больше накладных расходов.

Я бы предположил, что AOT, вероятно, по-прежнему имеет больше шансов ускорить процесс, но вы правы, что, скорее всего, слишком рано исключать интерпретатор, поскольку большинство веб-приложений даже не имеют таких высоких требований к производительности и, скорее всего, будут в порядке. с интерпретированной версией.

Более эффективный AOT имеет значение не только для интенсивных приложений. Это также важно для мобильных и других недорогих платформ, особенно если учесть использование батареи.

Есть ли в настоящее время какой-либо реальный способ включить компиляцию AoT для проектов Blazor? Я продолжаю читать сообщения в блогах, в которых утверждается, что у Blazor уже есть режим AoT; Если это правда, может ли кто-нибудь указать на статью, в которой объясняется, как это включить?

@TheFanatr компиляция AOT зависит от моно, поддерживающего эту функцию. Насколько я могу судить, последнее обновление по этой теме было от @migueldeicaza в Blazor Gitter .

Мигель де Икаса (2018-06-08 19:01):
Мы работаем над этим. Произошло вот что:
Интерпретатор использует «emscripten», который имеет довольно полную библиотеку, на которую мы можем положиться. А наш движок AOT был построен на чистом LLVM, что требует от нас написания полной библиотеки libc. Последнее - идеальное место, потому что мы получаем нативные линкеры, немедленную поддержку llvm и так далее. Но woudl отправит нас по пути написания этой библиотеки libc.
Итак, в краткосрочной перспективе мы переходим на emscripten компилятор AOT, убедитесь, что мы сохраняем совместимость. Обратной стороной является то, что инструментарий emscripten старше, поэтому многие из лучших частей, такие как компоновщик LLVM, недоступны. Итак, мы работаем над этим.
По сути, у нас что-то было сделано, но мы должны были начать с нуля, чтобы работать с тем, что у нас есть, не заставляя нас писать и эмулировать все самостоятельно. Мы могли бы попытаться совместить эти две вещи, но это тоже серьезное усилие. Так что мы думаем, что можем сделать emscripten сейчас, используя несколько хитрых хаков здесь и там.

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

В CoreRT только что был отмечен довольно большой прогресс !!

https://github.com/dotnet/corert/issues/4659#issuecomment -425690500

у кого-нибудь есть идея, что это блокирует? Я мог бы быть готов потратить несколько триллионов человеко-часов, чтобы увидеть, как AOT произойдет раньше, чем позже, теперь, когда власть, находящаяся в Microsoft, взяла на себя обязательства по внедрению клиентского блейзера. AOT будет действительно важен, если мы хотим разработать (отличные) PWA с Blazor.

@honkmother AoT https://github.com/mono/mono . Я уверен, что они будут рады вашей помощи! В этом выпуске отслеживается использование их работы, когда она будет готова.

Я думаю, что у меня есть несколько связанный с этим вопрос, но он не очень хорошо продуман и плохо сформулирован - я экспериментировал с ILRepack и Blazor, и мне удалось упаковать большинство dll в один монолитный объект. Вы, ребята, собираетесь в какой-то момент упаковать общие библиотеки в одну dll?

@honkmother В настоящее время у нас нет конкретных планов сделать это, но нам было бы интересно услышать результаты ваших экспериментов.

Мне удалось объединить большинство из них вместе, просто используя ILRepack в / dist / bin / output и включая System.Core.dll. После объединения большинства библиотек время запуска было улучшено, но при этом появилось множество головокружительных ошибок, которые я не знаю, как решить; и, конечно же, вы теряете возможность полагаться на кеширование обновленных фрагментов кода без повторной загрузки всего большого двоичного объекта.

Были ли какие-то изменения в этом или, по крайней мере, в ETA? Серверная часть работает достаточно хорошо, но производительность WASM на стороне клиента через интерпретатор по-прежнему неприемлема, как только DOM становится достаточно сложной.

Я так не думаю, AOT в монорепо все еще кажется незавершенным; Я слышал, что он будет к первому кварталу 2020 года, но не знаю, наверняка ли это; что печально, потому что у меня есть очень хороший PWA, настроенный на стороне клиента, но у него есть некоторые проблемы с производительностью, которые AOT, вероятно, устранит, не прибегая к грязным взломам.

А пока есть некоторые вещи, которые вы можете сделать, чтобы облегчить там боль, а именно использовать виртуальную DOM и / или напрямую использовать RenderTreeBuilder, чтобы вы не рендерили все сразу и не имели некоторого контроля над тем, что происходит.

Что ж, мне также было интересно, изменилось ли что-нибудь в свете объявления о .NET 5 несколько месяцев назад. Интересная цитата там:

Проект Blazor уже использует Mono AOT. Это будет один из первых проектов, которые перейдут на .NET 5. Мы используем его как один из сценариев для подтверждения этого плана.

Знают ли они то, чего не знаем мы?

А пока есть некоторые вещи, которые вы можете сделать, чтобы облегчить там боль, а именно использовать виртуальную DOM и / или напрямую использовать RenderTreeBuilder, чтобы вы не рендерили все сразу и не имели некоторого контроля над тем, что происходит.

Действительно. Я создаю платформу MVVM с нуля, вдохновленную WPF, и первое, что я делаю, - это переопределяю ShouldRender чтобы отключить триггеры автоматического рендеринга Blazor, и вместо этого полагаюсь на изменения свойств, чтобы сообщить компонентам, когда нужно выполнить повторный рендеринг. Фактически, одно улучшение производительности HUUUUGGGE происходит за счет обновления стилей через JS-взаимодействие, а не StateHasChanged , когда это возможно.

Тем не менее, у меня возникают проблемы, когда необходимо заранее сгенерировать большие модели DOM - например, сложный список или сетку данных. На стороне сервера все в порядке, но на стороне клиента иногда требуется 5-10 секунд только для первоначального рендеринга.

Что нам действительно нужно, так это VirtualizingPanel, как в WPF. Я много думал о том, как это можно реализовать в Blazor и JS-взаимодействии, но полное решение все еще ускользает от меня. В WPF это работает, потому что фреймворк отвечает за измерение каждого визуального элемента и сообщение его размера. Даже с JS-взаимодействием я не уверен, что то же самое возможно, и я еще не видел хорошего обобщенного решения для этого в какой-либо веб-платформе.

SyncFusion имеет некоторые компоненты виртуализации, а именно представление списка - не знаю, как они работают, но я их использую. Может, захочешь их проверить.

Также стоит посмотреть https://github.com/SamProf/BlazorVirtualScrolling .

О да, я это видел. Рад знать, что это хорошо работает для вас. У него есть существенные ограничения, заключающиеся в том, что требуется единообразная высота элемента и что высота должна быть известна заранее. Но это могло быть временным решением.

Может ли кто-нибудь пометить эту проблему тегом blazor-wasm? Трудно найти эту проблему среди всех проблем с сервером (или хостинг-агностиком) Blazor.

А для тех, кто ищет обзор выполняемой работы Mono WASM AOT, я нашел эту ссылку:
https://github.com/mono/mono/projects/11

Ваше желание - моя команда 😆

Спасибо, это очень помогло!

Возможно ли получить хотя бы самые смутные оценки того, когда мы сможем начать использовать AOT-скомпилированный WASM с Blazor, даже экспериментально? 6 месяцев? Год? Кто-нибудь из команды Blazor действительно смог заставить его работать даже в специальной манере?

Немного рискованно начинать вкладывать много времени в Blazor на стороне клиента или планировать его, когда мы все еще действительно не знаем, как будет выглядеть конечный продукт. Как и на стороне сервера, нам действительно нужна надежная и производительная версия на стороне клиента, чтобы это было жизнеспособным.

Я разместил этот вопрос здесь https://github.com/mono/mono/issues/10222, но получил ответ, что это неправильное место. Репост здесь:

Было объявлено, что Blazor WASM будет выпущен в мае 2020 года. Можно ли предположить, что в настоящее время это будет родное приложение WASM? Каков правильный ответ?

1. да.
2. Мы попробуем, но мы не уверены.
3. Нет, он будет доступен в ноябре 2020 года с .NET 5.0.
4. Нет, и пока у нас нет дорожной карты.

Для всех поклонников Blazor очень важны две вещи:

• Скорость выполнения - в некоторых случаях интерпретатор работает медленно.
• Размер загрузки - надеюсь, вы сможете достичь размера WASM, аналогичного текущим .NET DLL, и мы сможем полностью удалить mono.wasm (я считаю, что этот файл содержит только интерпретатор IL - я прав?).

Я большой поклонник Blazor с самого начала. Я знаю, что серверная часть Blazor имеет некоторые преимущества для некоторых людей, но мы все ждем настоящей революции - быстрого и надежного Blazor в браузере.

Спасибо вам, ребята, за вашу тяжелую работу !!!

@ Andrzej-W Это может ввести в заблуждение любого, кто просматривает это и предполагает, что ноябрь 2020 года является каноническим выпуском.

Лично я слышал, что он должен выйти официально примерно в первом квартале 2020 года.

На самом деле ничто не мешает нам внедрить его в наши процессы сборки прямо сейчас, насколько мне известно, кроме раздутого размера исполняемого файла и того факта, что он еще не поддерживается Microsoft.

На самом деле ничто не мешает нам внедрить его в наши процессы сборки прямо сейчас, насколько мне известно, кроме раздутого размера исполняемого файла и того факта, что он еще не поддерживается Microsoft.

Кто-нибудь пробовал это? Я думаю, что для нас важно иметь хотя бы доказательство концепции, чтобы мы могли увидеть, как она работает по сравнению с интерпретируемой и по сравнению с серверной. Я знаю, что размер exe - это то, над чем работает команда mono, и это важно, но скорость приложения - это король. (И время компиляции действительно не имеет значения IMHO, потому что мы будем выполнять отладку на стороне сервера и компилировать только в собственный WASM для выпуска. Время компиляции для веб-пакета тоже может быть довольно отвратительным).

На .NET Conf мы объявили, что первый выпуск Blazor WebAssembly запланирован на май 2020 года. Мы ожидаем, что для этого первого выпуска Blazor WebAssembly среда выполнения по-прежнему будет основана на интерпретаторе IL, который мы используем в настоящее время.

Команда среды выполнения .NET работает над поддержкой предварительной компиляции для компиляции непосредственно в WASM. Преимущество этого подхода заключается в повышении производительности во время выполнения, но за счет размера приложения.

Для первоначального выпуска Blazor WebAssembly в мае мы изучаем возможность запуска интерпретатора IL в смешанном режиме, когда горячие пути компилируются в WASM, а остальная часть приложения - это сборки .NET. Это обеспечивает хороший компромисс между производительностью во время выполнения и размером приложения. Однако пока не ясно, произойдет ли это к маю.

В долгосрочной перспективе мы хотим предоставить SDK, который дает разработчику приложения контроль над тем, какие части его приложения компилируются непосредственно в WASM. Пока нет плана, когда будет доступен такой SDK.

@lewing @richlander

Спасибо @ danroth27 за объяснение. Размер загрузки может быть частично замаскирован предварительным рендерингом на стороне сервера - убедитесь, что этот https://github.com/danroth27/ClientSideBlazorWithPrerendering будет работать во всех будущих (предварительных) выпусках Blazor.

@ danroth27 спасибо за обновление! Один уточняющий вопрос - относится ли «команда времени выполнения .NET» к группе Mono, CoreRT, .NET 5 или чему-то еще?

@legistek Теперь они все одна команда: smile :. Однако технология основана на среде выполнения Mono.

Ах да, я забыл. ; D Я хотел понять, является ли

@legistek Ага , вся работа .NET WASM в настоящее время происходит в монорепозитории.

Я создал довольно сложное приложение, работающее на стороне сервера Blazor, и оно работает очень хорошо. (WASM через интерпретатор IL, однако, настолько медленный, что его невозможно использовать).

Я очень хочу знать, как это будет работать с скомпилированным WASM.

Если мы пока проигнорируем размер загрузки или время компиляции, есть ли способ AOT скомпилировать приложение Blazor в WASM и опробовать его? В монорепозитории (https://github.com/mono/mono/issues/10222) люди публикуют несколько примеров AOT с другими платформами, такими как Uno, но я еще не видел примера Blazor, не говоря уже об инструкциях о том, как сделать это.

Я понимаю, что на этом этапе процесс сборки будет полностью спонтанным, но возможно ли это даже в принципе, чтобы мы могли хотя бы приблизиться к разнице в производительности? Мне нравится серверная часть для отладки и демонстрации, но я не знаю, жизнеспособна ли она для промышленного развертывания в масштабе. Таким образом, я не решаюсь проделать еще большую работу над этим проектом, пока не узнаю, что производительность AOT WASM будет хорошей. Я должен представить, что в одной лодке много людей.

Чтобы продолжить, я закончил опробовать загрузочную программу Uno WASM с использованием WSL (описанную здесь ), и она действительно работает довольно хорошо. Эта проблема здесь по-прежнему помечена как ЗАБЛОКИРОВАНО, и хотя я знаю, что они все еще работают над уменьшением размера полезной нагрузки, похоже, что она не должна блокировать работу над цепочкой сборки AOT для Blazor, даже если на данный момент это просто Linux. Это происходит, и если нет, чего команда Blazor ждет от команды Mono перед тем, как это начать?

@legistek вы

Я создал подмножество своего приложения, а затем просто проверил некоторые показатели производительности, поскольку я не мог запустить все это без начальной загрузки Blazor.

Что касается математики (генерация случайных чисел и простая арифметика), я обнаружил, что AOT примерно в 40 раз быстрее, чем интерпретируемый.

Что меня действительно интересовало, так это вещи, которые, как я знал, будут неэффективными, например, отражение и манипуляции со строками. В моем приложении есть настраиваемая структура привязки данных, аналогичная WPF, поэтому я попытался настроить сложную привязку данных и 10 000 раз изменить значение на случайную строку. Вот результаты:

Интерпретация моно IL: 2,49 с.
Полный AOT (Chrome): 0,702 с
Полный AOT (Firefox): 0,5 с
Исходный: 0,067 с

Таким образом, мы имеем наихудший сценарий, когда AOT будет примерно в 4 раза быстрее, чем интерпретируемый IL, но в лучшем случае - до 40 раз.

Думаю, этого, наверное, и следовало ожидать.

К сожалению, это все еще не говорит нам, насколько хорошо Blazor AOT будет работать по сравнению с интерпретируемым, но я немного пессимистичен, что он будет на более низкой стороне (4-5x), потому что Blazor предположительно выполняет много манипуляций со строками для создания DOM, а также сложный SPA будут выполнять множество вызовов API JSON (которые, конечно, широко используют отражение и строки). Но на самом деле мы не можем быть уверены, пока не сможем действительно опробовать настоящее приложение Blazor с AOT.

Я предполагаю, что в ближайшем будущем производительность будет значительно улучшена, поскольку производители браузеров начнут более серьезно относиться к WebAssembly.

Я думаю, что AOT заслуживает гораздо большего расследования раньше, чем позже, потому что Blazor, скорее всего, выживет или умрет из-за репутации его клиентской реализации в WASM.

Такие проекты, как https://d07riv.github.io/diabloweb/, без сомнения, доказывают, что WebAssembly более чем способен справиться с самим собой, но я еще не видел столь же впечатляющего доказательства концепции, работающей на Mono + WASM.

Вопрос открыт два года .. Есть ли подвижки?

@partyelite Да, прогресс есть. В репозитории https://github.com/mono/mono реализована AoT-компиляция для WASM, а среда выполнения была обновлена ​​для поддержки выполнения смеси .NET IL и скомпилированных файлов WASM. Однако поддержка AoT не будет готова к предстоящему выпуску в мае. Мы вернемся к его выпуску для .NET 5.

Я попробовал вариант компиляции AOT, о котором говорит Дэн, и он хорошо работает с Uno.

Я все еще ломаю голову над тем, почему еще нет хотя бы PoC, работающего с Blazor? Я понимаю, что набор инструментов - это все еще Linux, а выходные файлы намного больше, чем мы в конечном итоге хотим, но что мешает создать пример приложения Blazor, работающего с AoT, чтобы мы могли оценить производительность и осуществимость?

Я не уверен, связано ли это, но в репозитории Syncfusion некоторое время назад сообщалось о проблеме с производительностью (https://github.com/syncfusion/blazor-samples/issues/50), которая, как утверждается, была вызвана медленная производительность моно.

В моем анализе проблема производительности сводится к вызову js_to_wasm :

Это что-то, что решит эта и моно-команда? Или это что-то не связанное?

@Herdo это может быть связано с этим: https://github.com/dotnet/aspnetcore/issues/5617

Проверьте журнал веб-консоли, чтобы убедиться, что сборщик мусора не происходит чрезмерно. Кажется, это встроено в среду выполнения WASM Mono и должно быть настроено IMO.

@honkmother ,
Не могли бы вы поделиться дополнительной информацией о том, как вам удалось упаковать библиотеки DLL Blazor с помощью ILRepack? Я использовал ILRepack.MSBuild.Task, как описано здесь . Упаковка проходит успешно, но когда я запускаю приложение, я всегда получаю эту ошибку:

WASM: System.IO.FileNotFoundException: не удалось загрузить файл или сборку netstandard, версия = 2.1.0.0, культура = нейтральная, PublicKeyToken = cc7b13ffcd2ddd51 или одну из их зависимостей.

Похоже, что упаковка что-то ломает или в списке мешает правильная загрузка приложения.

хм AOT есть в UNO . Можете ли вы разработать это решение?

.Net 5 не поддерживает компиляцию AoT для Blazor?

Это тоже вычеркнуто из дорожной карты.

Я хотел бы услышать официальный комментарий, прежде чем делать выводы, но если это правда, это очень плохая новость, которая не только влияет на Blazor, но и заставит меня переоценить сам .NET как платформу внешнего интерфейса.

На стороне Mono в течение нескольких месяцев также не было зарегистрировано активности:
https://github.com/mono/mono/issues/10222

Может быть, пора сократить убытки и вместо этого сосредоточиться на CoreRT.

@ ram16g @legistek Мы работаем над улучшением производительности среды выполнения Blazor WebAssembly в .NET 5 (и более поздних версиях ). AoT все еще находится в нашей долгосрочной дорожной карте, но его реализация займет больше времени, чем у нас есть время в .NET 5. Первым шагом к AoT является перемещение Blazor WebAssembly для использования тех же основных библиотек .NET, которые используются .NET Core, что также должно повысить производительность. Это работа, которая идет прямо сейчас. Затем нам нужно решить, как заставить AoT хорошо работать с привязкой IL. На данный момент мы думаем, что нам понадобится до первого квартала следующего года (ранние предварительные версии .NET 6), чтобы сделать первые предварительные версии поддержки .NET AoT для WebAssembly общедоступными. Но даже без AoT мы по-прежнему ожидаем существенного улучшения производительности Blazor WebAssembly в .NET 5.

Привет @ danroth27 , сейчас меня беспокоит не столько общая производительность, сколько начальная производительность при запуске? Каждое посещение страницы занимает 2-3 секунды, пока не загрузится фактическая страница, пока не загрузится среда выполнения, скомпилированные библиотеки и т. Д. Будут ли улучшения без AOT? Или нам нужно полагаться на предварительную отрисовку?

Привет, @MichaelPeter. Время начальной загрузки страницы определяется загрузкой приложения и запуском среды выполнения. AoT в этом не поможет. AoT предназначен для повышения производительности во время выполнения, а не для уменьшения размера загрузки приложения. Для сред выполнения на основе JIT AoT может улучшить производительность запуска, поскольку вы избегаете необходимости JIT во время выполнения, но Blazor WebAssembly использует среду выполнения на основе интерпретатора IL без какой-либо поддержки JIT.

По всей вероятности, AoT действительно увеличит размер приложения для загрузки, потому что .NET IL - более компактный формат, чем его изначально скомпилированное представление. Таким образом, использование AoT, вероятно, приведет к компромиссу между повышением производительности во время выполнения за счет увеличения размера загрузки. В настоящее время мы думаем, что мы сделаем инструментальную цепочку AoT доступной для разработчиков, чтобы вы могли решить, какую часть вашего приложения вы хотите использовать в AoT, а затем приложение будет работать в смешанном режиме, где некоторые из приложений по-прежнему работают как .NET IL. , а критические пути производительности предварительно скомпилированы в WebAssembly.

Чтобы улучшить производительность запуска приложения, мы планируем дальнейшие улучшения компоновщика .NET IL, а также работаем с библиотеками ядра фреймворка, чтобы сделать их более связанными. Мы также планируем проверить производительность самой среды выполнения при запуске после ее загрузки.

@ danroth27 Есть ли какие-либо проблемы, за которыми я могу следить за прогрессом в производительности запуска приложения? На данный момент меня больше всего беспокоит блейзер.

@ danroth27 : +1: Большое спасибо за информацию, я в основном использую Blazor в LAN envoirements, где время загрузки должно быть почти нулевым, и думал, что браузер кэширует файлы. В любом случае, Net DLL. Но в вопросе запуска мне тоже было бы очень интересно.

Обратите внимание, что время запуска приложений на основе WebAssembly, таких как интерпретатор Blazor, может зависеть от того, правильно ли браузер кэширует файлы. Если веб-сервер, на котором размещено ваше приложение, настроен неправильно, файл был изменен или браузер не может кэшировать приложение иным образом, ему придется перекомпилировать его с нуля каждый раз, когда вы запускаете приложение. В идеальных условиях браузер может кэшировать его, поэтому будущие посещения после вашего первого посещения начнутся намного быстрее.

Вы можете увидеть https://v8.dev/blog/wasm-code-caching для получения информации об этом. Firefox имеет аналогичный механизм, и я считаю, что Safari тоже, но я не уверен.

@ danroth27 Я очень ценю объяснение и позицию, в которой вы пытаетесь подготовить .NET 5 вместе со всем остальным. Некоторые комментарии / вопросы:

Первым шагом к AoT является перемещение Blazor WebAssembly для использования тех же основных библиотек .NET, которые используются .NET Core, что также должно повысить производительность.

Я полагаю, вы имеете в виду переход на CoreFX с Mono mscorlib? Я думаю, что это отличный шаг, учитывая многие опубликованные тесты производительности, показывающие, что CoreFX значительно превосходит Mono (и NetFX в этом отношении).

Затем нам нужно решить, как заставить AoT хорошо работать с привязкой IL.

Да, связывание было серьезным препятствием в течение некоторого времени, как уже обсуждалось здесь . Тем не менее, Uno удалось создать цепочку инструментов и найти баланс между интерпретируемым и скомпилированным, что позволяет получить размеры приложения в диапазоне ~ 10 МБ или ниже подросткового диапазона. Я бы подумал, что у нас будет хотя бы PoC для этого на стороне Blazor, просто чтобы начать оценивать показатели производительности. Непонятно, в какой степени улучшится производительность, что вызывает наибольшее беспокойство прямо сейчас.

Мы также планируем проверить производительность самой среды выполнения при запуске после ее загрузки.

Необходимо внимательно изучить и строительный элемент DOM. Загрузка пустого приложения Blazor занимает 1-2 секунды на моем рабочем столе и еще пару секунд на мобильном телефоне. Живя в мире Angular, я привык видеть «Загрузка ...» каждый раз и считаю, что базовое время запуска подходит. Более серьезная проблема - мучительно медленные скорости построения сложных DOM. Даже модели DOM с 1000–2000 элементов добавляют 5–10 секунд для начальной загрузки, а интерактивность с участием сложных элементов также приводит к значительному запаздыванию. Я не вижу, чтобы об этом много говорили, и я беспокоюсь, что (1) AOT не решит эту проблему, потому что это присуще взаимодействию WASM / JS и способу обмена строками между ними; и (2) механизм рендеринга / дифференцирования в Blazor настолько внедрен, что уже слишком поздно менять его на что-то более производительное.

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

Точно так же, как Уно уже делает ...

Итак, вот моя реакция и анализ всего этого, и я хочу, чтобы вы и все остальные поняли, что я подхожу к этому как кто-то, кто, вероятно, такой же большой поклонник .NET и Microsoft, как и когда-либо. Blazor был представлен миру как структура для использования _webassembly_, чтобы вернуть .NET в браузер. Я был в восторге, когда узнал об этом. Но прошло уже более двух лет с тех пор, как он был впервые представлен для предварительного просмотра, а часть веб-сборки все еще не готова для потребительских приложений из-за серьезных проблем с производительностью. Между тем, много было вложено в серверную часть (место которой я до сих пор не совсем уверен) и теперь, возможно, мобильная через Xamarin, но WASM может снова и снова попадать в цель.

.NET потерял так много позиций в качестве интерфейсной веб-платформы с тех пор, как к власти пришли SPA, а Silverlight умер из-за запрета плагинов Chrome. Blazor мог все это изменить. Но я не могу сказать прямо сейчас, действительно ли Blazor WASM задуман Microsoft как средство изменения стратегии игры, или это просто любопытство для фанатов вроде меня. Но фанат или нет, но как владелец бизнеса, если я сегодня выбираю интерфейсный фреймворк для нового проекта или переделываю старый, как я могу оправдать своих сторонников, что Blazor - лучший вариант, а не React или Angular? Когда я перечисляю плюсы и минусы, с чем я остаюсь как профессионал, кроме того, что мне нравится C #? Минусы же, напротив, продолжают расти.

Так что я очень разочарован и немного деморализован. Дело не только в том, чтобы ждать дольше, а в том, что все еще есть много сомнений в том, будет ли эта технология когда-либо жизнеспособной, и я, например, ждал, чтобы увидеть AoT, чтобы я мог сделать это определение.

Я не ожидаю, что вы, ребята, измените свою дорожную карту или действительно сможете решить любую из этих проблем сегодня, но я подумал, что их стоит озвучить. Я отчаянно хочу, чтобы это удалось, и больше всего мне хотелось бы, чтобы .NET вернула себе место короля интерактивных веб-приложений. Но если бы мне пришлось поставить на это сегодня деньги, это не выглядело бы хорошей ставкой. Пожалуйста, докажите, что я ошибаюсь!

Я должен сказать, что я в той же ситуации, что и @legistek. Я использую Blazor версии 0.1, и я большой поклонник этой технологии. Конечно, для некоторых из нас приятно иметь возможность запускать Blazor на сервере. Также интересно иметь Blazor на мобильных устройствах, но я искренне верю, что реализация WebAssembly должна иметь наивысший приоритет. Это изменит правила игры, это будущее.

@ danroth27 для blazor скорость десериализации JSON чрезвычайно медленная для больших списков объектов, есть ли какие-либо рекомендации о том, как сделать это быстро, а не использовать медленный в настоящее время способ интерпретатора.

Я считаю, что это худшее снижение производительности в Blazor, если используются rest apis и данные больше, тогда как javascript не влияет на размер примерно так же.

Если для этого требуется процесс десериализации вручную, который подойдет для больших списков, просто интересно, есть ли какие-то рекомендации по этому поводу. В идеале мы могли бы использовать десериализаторы AOT?

Чтобы сократить время запуска, я предлагаю отложенную загрузку. Имеется в виду загружать только те библиотеки DLL, которые необходимы для определенного вида или страницы. Это действительно ускорит запуск

@ ram16g @legistek Мы работаем над улучшением производительности среды выполнения Blazor WebAssembly в .NET 5 (и более поздних версиях ). AoT все еще находится в нашей долгосрочной дорожной карте, но его реализация займет больше времени, чем у нас есть время в .NET 5. Первым шагом к AoT является перемещение Blazor WebAssembly для использования тех же основных библиотек .NET, которые используются .NET Core, что также должно повысить производительность. Это работа, которая идет прямо сейчас. Затем нам нужно решить, как заставить AoT хорошо работать с привязкой IL. На данный момент мы думаем, что нам понадобится до первого квартала следующего года (ранние предварительные версии .NET 6), чтобы сделать первые предварительные версии поддержки .NET AoT для WebAssembly общедоступными. Но даже без AoT мы по-прежнему ожидаем существенного улучшения производительности Blazor WebAssembly в .NET 5.

Всем привет и @ danroth27 , насколько это улучшит скорость запуска (при условии, что все файлы кэшируются)? Что я могу сделать, чтобы доставить ребенка к ноябрю? Я больше не люблю использовать angular. ахахахаха, я готов предложить бесплатное кодирование, чтобы ускорить это. Меня действительно не волнует начальный размер загрузки, потому что он будет просто кеширован. Пользователи - частые посетители. angular может запускаться мгновенно, когда файлы кэшируются.

@hoksource У нас нет точных данных о том, как изменятся характеристики производительности, однако, если вы попробуете превью через 1-2 месяца, вы сможете узнать.

@hoksource У нас нет точных данных о том, как изменятся характеристики производительности, однако, если вы попробуете превью через 1-2 месяца, вы сможете узнать.

@SteveSandersonMS, ладно, так
Моя цель - уметь делать следующее:

Вариант 1: Прямой подход (решать проблему напрямую):
[] научиться компилировать монопроект
[] научитесь компилировать проект asp.net Blazor
[] научитесь компилировать asp.net blazor с помощью webassembly
[] научитесь компилировать клиентскую программу Blazor для веб-сборки полностью aot (моно-> веб-сборка еще не выполнена? может ли она объединить все ссылочные двоичные файлы в один файл wasm?)
[] проверьте, может ли mono скомпилировать весь проект веб-сборки в веб-сборку.
[] выяснить, как поддерживать все отсутствующие языки c # /. net в веб-сборке
[] определить оптимальную структуру ссылок для преобразования всех dll в один файл wasm или несколько файлов wasm
[] выяснить, как лучше всего сделать это, взвесив размер файла и производительность
[] Изучите / спроектируйте связывание и объединение двоичных файлов с одной веб-сборкой или разрешите ленивую загрузку с частичными сборками
[] имеют разный набор решений, выберите несколько лучших решений, представьте их вам, ребята. через какую-то ветку публичного / частного репозитория из текущего проекта

Вариант 2: (решить проблему косвенно)
[] Я буду выполнять небольшие простые задачи, такие как маленькие / простые модули / проектирование / документирование, верю, что более опытные инженеры / дизайнер могут сосредоточить / направить свои ресурсы на прямой подход, указанный в варианте 1 до выпуска nov .net 5.

• дополнительный вопрос. все ли справочные библиотеки должны быть с открытым исходным кодом? У меня есть код довольно много библиотек, но я не уверен, хочу ли я раскрыть их все публично.

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

@hoksource Спасибо за вашу готовность принять участие. В настоящее время единственный практический вариант - это вариант 1, поскольку команда ASP.NET Core полностью занята другой работой. Я знаю, что вам придется разобраться в огромном количестве вещей, но, надеюсь, это поможет объяснить, почему это не то, что мы можем просто проскользнуть в этап .NET 5 :) Похоже, у вас есть хорошее понимание в круг необходимых вещей.

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

Вам решать, что делать с открытым исходным кодом, а что нет. Сам по себе ASP.NET Core имеет открытый исходный код, но вы можете создавать на его основе вещи с закрытым исходным кодом, если хотите. Мы можем включать в наше репо только вещи с открытым исходным кодом.

Для сред выполнения на основе JIT AoT может улучшить производительность запуска, поскольку вы избегаете необходимости JIT во время выполнения, но Blazor WebAssembly использует среду выполнения на основе интерпретатора IL без какой-либо поддержки JIT.

Из любопытства: будет ли JIT для клиента практической альтернативой интерпретации / переходу на полный AoT?

Привет народ! Просто поговорил с некоторыми командами и так далее. Кажется, это очень важно для таких библиотек, как SkiaSharp. Основная часть SkiaSharp - это собственная библиотека, а на выходе получается, по сути, файл .a, который должен быть статически связан. Мы _could_ потенциально можем создать динамическую собственную библиотеку, но поддерживает ли Blazor это вообще?

К вашему сведению, в настоящее время можно статически связать собственную библиотеку со средой выполнения. Это не то, что я бы рекомендовал, поскольку это нетривиально, но вы можете сделать это, а затем p / вызвать статически связанную библиотеку, когда все части будут там. Я не знаю, есть ли у нас какие-либо тестовые примеры, которые позволяют это сделать, поэтому может потребоваться дополнительная инфраструктура, которой пока нет в Blazor. Вам нужно будет скомпилировать свой собственный dotnet.wasm / dotnet.js для интеграции с вашими сборками Blazor, что не для слабонервных.

Другое дело, динамические собственные библиотеки, я понимаю, что инструменты для этого в wasm в целом не очень хороши прямо сейчас, прежде чем вы даже дойдете до вопроса о том, поддерживает ли их Blazor.

В прошлом году я узнал, что динамическое связывание на данный момент не является жизнеспособным решением. Emscripten подразумевает, что «основной» модуль wasm включает в себя все возможные комбинации системных библиотек, которые любая динамическая библиотека хотела бы использовать. Это делает для начала очень большой распространенный модуль wasm.

Некоторое время я пробовал использовать этот подход с Uno.SkiaSharp, но он был грубым и отложил это в сторону (в этот момент @vargaz, вероятно, воздержался от того, чтобы сказать «сказал вам об этом» 😂).

Загрузчик Uno теперь может использовать статическое связывание (указания здесь ) и P / Invoke через WSL в Windows, и, поскольку он использует те же пути выполнения, что и внутреннее взаимодействие System.Native, теперь он довольно стабилен. Таким образом вы даже можете легко взаимодействовать с модулями ржавчины .

Я немного читал, только среда выполнения .net преобразована в wasm. Все библиотеки загружаются и анализируются при запуске. похоже, что используемая среда выполнения wasm - моно. Теперь их цель - использовать вместо этого ядро ​​среды выполнения .net.

Текущий полный компилятор aot выполняется с помощью mono, но я не уверен, что полный aot с ядром .net должен быть путем / способом. (Понятия не имею, о чем я здесь говорю. Нужен эксперт)

Интернет говорит, что ядро ​​.net работает в два раза быстрее, чем mono, для вычислительных задач. Запуск связан с io, 1-я загрузка двоичных файлов .dll и зависимостей. (Несколько файлов) парсинг их в память. Затем запустите поверх него клиентское приложение blazor wasm. Загрузка занимает некоторое время (но может быть кэшировано), а анализ занимает некоторое время. Компилятор aot также не знает, какие зависимости Blazor зависят от конкретного приложения. Будет запутано, если вы всегда будете указывать, какую dll включать в aot wasm. Так что полный аот выглядит красиво. (Но это будет быстрее с реализацией основной среды выполнения .net вместо моно? Не уверен еще раз об этом) Я также не уверен, выполняется ли разработка / реализация полной компиляции aot wasm с помощью среды выполнения mono или .net. Также не уверен в прогрессе

@ danroth27 Есть ли прогресс?

Будет ли это доступно в .NET 5?
Было бы неплохо иметь предварительный релиз, чтобы также проверить эту функциональность;)

@redradist AOT не будет работать на .NET 5. Они оптимизируют blazor wasm. Но из того, что я читал, они занимаются сборкой и обрезкой полей. и оптимизация времени выполнения. надеюсь, что они смогут получить <1 запуск при кэшировании на мобильных телефонах. danroth27 комментарий

@hoksource

@redradist AOT не будет работать на .NET 5. Они оптимизируют blazor wasm. Но из того, что я читал, они занимаются сборкой и обрезкой полей. и оптимизация времени выполнения. надеюсь, что они смогут получить <1 запуск при кэшировании на мобильных телефонах. danroth27 комментарий

Это грустно :(

У меня вопрос. С Blazor AOT вы работаете над:

1. компиляция C # непосредственно в формат байт-кода WebAssembly
2. или вы работаете над преобразованием IL, скомпилированного в .NET DLL, в формат байт-кода WebAssembly

Подход 2) сохранит все инструменты .NET (включая наш), которые для работы полагаются на стандартный IL и скомпилированные метаданные, а также на PDB. Также 2) имел бы дополнительное преимущество, если бы System DLL также были скомпилированы в WebAssembly, возможно, с сокращенным кодом, который не выполняется во время выполнения (см. Проект Mono.Linker от @JbEvain).
Спасибо

Между прочим, есть много ресурсов о Blazor, но я не нашел тот, который с нужной степенью детализации, чтобы изучить Blazor Internals, поэтому написал его.

2 не 1

Кроме того, я надеюсь, что процесс AoT сгенерирует соответствующие исходные карты (от wasm до C #), чтобы упростить отладку.

Я надеюсь увидеть эту поддержку в первом квартале 2021 года для предварительных версий .Net 6. Это основа для поддержки таких репозиториев, как SkiaSharp, изначально работающих в веб-браузере.

Спасибо что связались с нами.
Мы переносим эту проблему на этап Next sprint planning для будущей оценки / рассмотрения. Мы оценим запрос, когда будем планировать работу на следующем этапе. Чтобы узнать больше о том, чего ожидать дальше и как будет решаться эта проблема, вы можете узнать больше о нашем процессе сортировки здесь .