Blazor wasm VS Angular. Катастрофический результат сравнения
ฝัง
- เผยแพร่เมื่อ 27 ก.ย. 2024
- В этом видео расскажу о том как сравнил производительность двух идентичных проектов Angular и Blazor wasm.
Исходники
github.com/Ale...
github.com/Ale...
это бенчмарк который я в итоге нашёл, как подтверждение своим же выводам.
takahirox.gith...
по больше б таких нормальных сравнений с разными технологиями и фреймворками)
Будет еще
Кроме скорости загрузки огромной страницы никаких других сравнений. Если у тебя сшарп программисте ты можешь сэкономит огромное деньги с razor, blazor, blazor server I xamarin.
Спасибо за такой материал. Очень нужное сравнение 👍
Хотел сравнить, вот получил...
Я на Blazor только с формами работаю, без графики. Всё нравится. Но, вероятно, чем сложнее фронтенд, чем больше графики, тем ситуация будет печальнее.
На самом деле тут дело не в графике, а в том что .net через wasm значительно тормознее чем обычный js. И да тут нагруженные страницы приходится оптимизировать, что будет на блейзоре...
Спасибо за информативное видео. Как раз искал что-то подобное и в топе поиска кликнул на видос не раздумывая)
Всегда пожалуйста 😊
Подскажите, а как вы снимаете себя таким образом, что в заднем фоне у вас ничего не было и остаётся только ваша голова и тело
у Nvidia есть такая возможность прога Broadcast
WASM должен выжить! и победить!
Да я не против, только он должен быть действительно быстрым + либо уметь то что умеет js, либо передача информации между js и wasm должна быть более гибкая и быстрая, а то через эти буферы как по мне очень не удобно
Я делал подобный тест 2 года назад и вот сейчас на NET7.
суть теста сравнение по скорости с VueJs:
Первый тест проверка скорости работы JS -> Blazor -> JS (последовательные команды на обновление DOM без использования Virtual DOM). Вышло что канал передачи данных JS -> Blazor -> JS в 3.5 раз медленнее чем JS -> Vue -> JS.. (т.е. замедление в 3.5 раза примерно, если из JS дергать Blazor и ждать результаты.
Второй тест был на скорость обработки DOM без Virtual DOM. Результаты: показали, что Blazor чуть отстает от Vue (где-то в 0.85 раз_
Третий тест обновление DOM с использованием Virtual DOM.. ну.. тут вышло что Blazor обогнал VueJS и даже JS. (там просто цикл у меня)
Вывод:
Blazor можно использовать, если он не общается интенсивно с JS. В идеале не трогать JS в принципе..
Сам тест выложу потом как NET8 выйдет
По результатам тестов Такахиро можно увидеть, что webAssembly проседает в основном на тестах вычисляющих double значения. С int там всё гуд.. так что +- скорость зависит от применения webAssembly.. например для тяжелых вычислений самое оно,
Как уже писал: дело еще в том что виртуальная машина .net поверх wasm работает.
@@TheBesogon да в моих вычислениях были double, но пробовал и single - ничего не поменялось
А пробовали аот ? Должно быть ощутимо быстрее в теории
А AOT компиляция была? Там вроде бы можно как-то умудрится оптимизировать Blazor WASM. И было бы круто ещё сравнение с Blazor Server
Конечно была, оба проекта на гитхабе можно проверить. Вывод => мёртвые пчёлы не жужжат
@@Kulibins1
На гитхабе в файле проекта не видно необходимого ключа RunAOTCompilation/true. Да и было бы круто сравнить цифры обеих режимов.
@@enter0prise когда делал на компе крутил и так и этак. Не помогает. Тут меня бесит что загрузка с бэка обычного json в разы медленее. Даже не хочется дальше этим заниматься - реально тупиковая ветвь. У меня довольно ресурсоёмкие проекты, и хоть я люблю c#, но лучше я на Angular фронт буду делать, который будет реально шустрым.
@@Kulibins1 где-то на хабре писали, что в хромиуме парсинг JSON чудным образом работает быстрее, чем создание объектов из литерала) с этим сложно тягаться, учитывая, опять же, копирование. Можно убрать затраты на рефлекшн с прегенерацией маппинга, но это вряд ли драматически изменит затраты. У вас интересный тест вышел, по самым больным местам блейзора)
А можно пример исходников алгоритмов, которые используются для построения карты? Они меня прям в сердечко поразили)
Алгоритмы простейшие в этом примере, все алгоритмы в моём большом коммерческом проекте.
вот исходники того что показываю в видео
github.com/AlexanderZhelnin/blazor-webassembly
github.com/AlexanderZhelnin/angular-map
Спасибо! Александр, а покажите хотя бы кусок той портянки с данными, из которой вы рисуете на канвасе?)
github.com/AlexanderZhelnin/blazor-webassembly/blob/main/wwwroot/sample-data/primitives.json
@@Kulibins1 Скажите, а эти данные выгружаются из какого то редактора?
@@dasvas9383 да из моего 🤣 ГИС Сфера
@@Kulibins1 Аахах)) Ну значит правильно подумал)
Спасибо. Хорошее сравнение. Только думал посмотреть на blazor) лучше на ангулар)
Код blazor просейший, с точки зрения программистат всё красиво и понятно. Но результат.... json 5.5 Mb
Исходники в описании
А что тут удивительного если в wasm нет jit? Надо было пробовать с AOT компиляцией хотя бы.
И опять же - blazor никогда не будет быстрее на клиенте, пока ему надо будет дергать JS при работе с DOM.
Я тут разделил вычисление и отрисовку, тут даже вычисления не конкурентоспособны. Что бы и другие видели на примере, что смысла пока в blazor нет. И как я сказал проверял после публикации в релизе. Простой запуск намного печальнее
@@Kulibins1 Ну имхо для каких то внутренних приложений, которые у вас были на формах/вебформах вполне вариант.
А так старый моно рантайм, кучу интеропа с JS(вот например когда вы используете канвас) - все это даёт печальную производительность.
Ещё производительность в разных браузерах кардинально различается. Если в хроме скажем всё ещё более или менее, но попробовав тестовый проект в файрфоксе можно инсульт словить 😄
@@fgdfgh я предлагаю перейти на любой нормальный современный framework: Angular, React, Vue. Мне Angular нравится, он ближе к wpf, и очень хорошо ложится на все что вы знали. Я winforms не занимался с .net framework 3.0, но думать что код форм через обертку будет летать на blazor, по моему мнению - утопия.
А если попробовать Блейзор с АОТ сбилдить (кажись запаблишить надо будет)?
Так тоже пробовал. Не помогает. Сама суть трансляции через was тормозит
на нет 8 или 9 не пробовали перезапустить?
@@silaevanton1844 на 8 пробовал, ссылки на исходники в описании, так что можно и на 9 запустить.
Чуваки пытаються сделать безопасную шморгалку , где браузер не будет считывать данные с клиента , а только связь клиент сераер , а браузер слеп
Интеропы из WebAsm в JS и обратно - очень медленно работают. Если делать на WebAsm - то делать надо все на вебасм, без канвасов, а используя Blazor библиотеки, тот же SyncFusion к примеру - тогда норм будет.
Как раз я оценил именно без туда-обратно, а вот если ещё и туда-обратно вообще катастрофа. Может если на C или Rust написать wasm будет получше, но тут всё плохо
@@Kulibins1 благодарю за ваше исследование - было интересно.
а если протестировать на .Net 8?
Позже проверю
вот еще сравнение) но здесь wasm(C++) показывает себя лучше github wasm-3d-animation-demo
я себе представляю где wasm будет лучше себя показывать, но тут можно и ошибаться думаешь будет лучше, потратишь кучу времени, а оно медленнее - будет обидно. Вообще у меня было в планах на C сделать wasm, но похоже даже не стану начинать, по крайней мере пока
@@Kulibins1 там есть ссылка на демку веб сайт и можно тестировать js и wasm увеличив количество скелетов, ещё показывает фпс память пинг
@@qweyn посмотрю
Вот интересно, я делаю на blazor мнемосхемы работающие в реальном времени, которые работают 24/7, тысячи анимированных графических элементов (canvas) и ничего не тормозит, и что я делаю нет так)) Не верьте таким обзорам, когда руки и голова на месте, будет и результат отличный.
исходники на гите, можете перепроверить. и главный вопрос какой тип рендеринга у вас: серверный или клиентский?
Понятно, что WASM будет просвживаться на интеропе. Было бы интересно попробовать рисовать в память, а потом уже готовую картинку копировать в JS.
Про скорость рисования я в этом видео даже не сравнивал. Тут простая математика ( кстати она же используется в виде для сравнения с node.js) и blazor медленее чем js 😕 мне хотелось обратного, но есть как есть.
@@Kulibins1
Честно говоря, я еще толком код не смотрел, но так понимаю, что в обоих вариантах рисуются примитивы на канвас, т.е. каждый раз доыгается интероп в JS. Если же свести эти вызовы к минимуму, передав однажды просто кусок памяти, может получиться не так уж сильно проигрывать)
@@Kulibins1
Пока wasm не умеет управлять памятью из JS (нет встроенного GC), всегда будет это чертово копирование на границе. Чем больше данных, тем печальнее цифры.
@@enter0prise нет, там я даже не сравниваю рисование примитивов, а сравниваю математику преобразования координат, каждый вызов рисования это возврат к js а это переход ооочень медленный, так вот просто преобразование координат получается медленнее чем в js. При том что если делать этот же код на бэке с c# то он будет на 40-50% быстрее. Но пересылка информации это тоже время, которое просто съест весь профит
@@Kulibins1
Боль) если математика проседает, то все безнадежно пока.
Не знаю, этот блейзер мне напоминает силверлайт и его ждет такой же конец :)
Силверлайт быстрее работал
А при чем сдесь angular, скорее typescript
причём тут TS ? ts всё равно в js преобразуется, тут именно плахая работа wasm, т.к. виртуалка поверх виртуалки, как результат обычный js быстрее
@@Kulibins1 в итоге конечно js, в ts в плане написания кода
@@hap123qwe код максималтно идентичный и там и там
Какой сложный проект. Честно говоря, просто было бы лень усилий для этого клипирования и так далее. Мое уважение, Александр.
это кусок из моего существующего ГИС Сфера2. Только это лишь часть расчётов, самые ресурсозатратные это отображение подписей, когда система атоматически определяет наилучшее положение текста, да ещё так что бы тексты не пересекались. Но в этом примере этого нет, тут всё просто 😊
@@Kulibins1 благодарю за пояснения. Вы молодец ✊
WebAssembly не имеет доступа к DOM. Глупо пытаться через него рисовать на DOM! WebAssembly совсем не для этого предназначен!!! Готовь картинки на WebAssembly, а выводи выводи свои готовые картинки через js.
Не нужно сравнивать WebAssembly в том, для чего он не предназначен!
Сравни не доступ к элементам DOM, а нормальный математический алгоритм на C# c компиляцией AOT и увидишь трехкратное преимущество. При этом ещё и уйму времени сэкономишь переиспользованием серверных библиотек.
В моём примере нет рисования именно в websssembly, я делал лишь подготовку данных. И получается у blazor очень медленно
@@Kulibins1 Я вам говорю - математика в разы быстрее работает.
Вы компиляцию AOT из IL в WebAssembly использовали? Наверняка нет. Тупо в режиме интерпретации IL через тормозной mono'вский интерпретатор запустили и удивляетесь...
Надо уметь применять технологию, а уж потом смешить весь интернет своим кликбэйтным "хейтом". А то у вас получается как в басне "Мартышка и очки"...
@@Alexander.Glazkov я уже говорил что запускал так. Исходник на гитхабе возьмите и проверьте в каком угодно режиме
@@Alexander.Glazkov очень медленно работает передать данные и получить обратно результат
Я просто похлопаю: настолько не владеть темой, и подогнать результат к желаемому. Я бы сказал "вон из профессии", но просто посоветую найти другую работу, где ценится натягивание совы на глобус.
Не согласны - опровергните. А то что blazor через wasm работает в разы медленнее очевидно. Наоборот я хотел что бы результат был обратный
нужен ретест на .нет8
Он как раз вышел. У меня будет неделя отпуска в конце ноября, сделаю ретест (это не так долго, как материал с нуля делать 🤣) Результат выложу на канале телеги, а если будет - вот прям интересные результаты, то сделаю видео.
А что же тогда последние пару лет все вокруг топят за server side rendering если это прошлое?
Вопрос. Кто топит? Может это последние попытки систем которые только и умеют серверный рендеринг? Вот из Angular за ненадобностью его убирают. Да и какие преимущества у серверного рендеринга?
Весьма годный, полезнейший контент на самом деле. Большое спасибо!
Всегда пожалуйста 😊
Сравнили с React?
@@sehrgutlocj Если делать оптимизированный код, то результат будет +/- идентичный
@@Kulibins1у нас сейчас в проект выбирают или react или blazor
@@sehrgutlocj Ничего не имею против вашего выбора
Чувак а ты думал о безопасности , сам браузер начиная с yandex, share , являеться программой которой владеют третие лица
@@Котован-м9и Не знаю яндекс браузер считается сертифицированным в России
Код выложил. Писал быстро, комменты почти не ставил, так что сори.
А ну да платежи те же ты будешь без серва принимать подумаешь спиздят всё
Пишите понятнее. а то мысль без контекста.
Не все время такой большая страница. Скорость у тебя наверно не больше чем 10. В США почти у всех скорость 100. После изначальной загрузки работает быстрее. Если сшарпом только работаешь то блазор спасает. В некоторых случаях можешь фронтенд на Джаваскрипт писат или часть. Сервер никуда не пропасть. Скорость интернета больше есче намного безопасно.
У меня запущено локально 🤣 и сервер и клиент. Тут явно дело не в скорости соединения. Тут проблема в том что виртуальная машина .net работает поверх виртуальной машины wasm. Если запускать просто c# то код минимум 2 раза быстрее чем js, но вот c# поверх wasm это дикий тормоз. Современный веб и так высоконагруженный и с моей точки зрения для серьёзных web приложений blazer не применим.
@@Kulibins1 Понятно. Всё таки карта большая по объёму. Есть много сайтов только на блейзер и 90% их так не захлебнутся как твоя карта. CNN и другие большие сайты на Джаваскрипт тоже буксуют. Джаваскрипт вместе с с# тоже один на голове второго.
@@arrrryyy на самом деле не очень и большой json, и его обычная загрузка очень тормозная.
вообще классно. интересно было
пожалуйста
Спасибо, полезное видео!
Всегда пожалуйста 😊
Как дела обстоят спустя год?
Не проверял. А что координально поменялось? Dotnet через wasm хорошо работать не будет. Недавно слышал аналогичную проблему от golang, у них есть трансляция в js и wasm, так вот js версия быстрее. Я как большой любитель c#, если бы хоть шанс был бы, то не стал бы так ругать blazor, но мертвые пчёлы не жужжат 🥺
А какой рантайм в блейзоре используется? Надеюсь, что в dotnet 6 и dotnet 7 это исправят
Тут 6-й. Не исправят 🤔
@@Kulibins1 жаль, а по синтаксису очень вкусно выглядел. Есть вроде как альтернатива opensilver комьюнити недавно зарелизили. Это как бы сильверлайт c#, dotnet и xaml но реализован на webassembly.
Интересно было бы взглянуть в сравнении, если будет возможность.
Ps. Спасибо за ответ
@@artursveshnikov7668 сам web assembly. Не имеет огромного преимущества пред js, а тут нужно сделать виртуальную машину, которая будет по верх него работать, замедление чудовищное. Тут даже если на C писать, код часто медленнее js, я тесты привел. Сам думал что идея интересная, но пока они сам веб ассембли, не сделают действительно быстрым...
что мертво умереть не может
@@dimitryk8429 наоборот, это все пока ещё в зародыше находится. Рано или поздно доведут до ума
"нативное" всегда быстрее, но не всегда удобнее... webgl для отрисовки вроде предпочтительнее, но рисовать на канве через несколько оболочек, уфф
Я тут даже не сравнивал именно рисование. Тут в Blazor медленно именно сам расчёт, получение с бэка обычного rest запроса, причём ооочень медленно. Если настоящий c# на бэке минимум на 40-50% быстрее в этой же задаче чем например node.js, то Blazor на несколько порядков медленнее чем простой js код (сравнение . net vs node.js смотри в моих последних роликах)
О какой версии WASM идет речь ?
Тут смотрю, то что с blazor с .net6 на самом деле тут все точно так же нужно оценивать накладные расходы что бы передать данные в was, а потом получить - это очень даже не бесплатная операция. И на этом примере видно что одна виртуалка поверх другой виртуальной машины хуже чем js
@@Kulibins1 WASM работает на V8 или SpiderMonkey. Ну и с чем не могу не согласиться. Жирные языки в WASM это какое-то извращение
@@vas_._sfer6157 да как оказалось и другие аля golang так же в wasm медленее.
@@Kulibins1 Goland тоже имеет жирный рантайм. Причем очень жирный. Да там нет виртуальной машины, но там очень хитрый сборщик мусора со своими взглядами на память.
Тут нужно смотреть в сторону Rust или C и C++. Хотя Rust здесь однозначный фаворит.
@@vas_._sfer6157 Цель этого видео показать, что Blazor не жизнеспособен 😔
рано еще на блейзор переходить? реакт + asp net core остается лидером??
на беке я .net core, а вот фронт Angular. Angular очень близок к тому что мы делаем на бэке, очень близок к wpf, он гораздо мощнее чем React. Но как уже говорил кому что нравится 😋
Профайлинг в релизе? А что, так можно было? Мы, просто, на плюсах пытаемся до вас дотянуться
Не понял вопроса
@@Kulibins1 Здравствуйте! А там вопроса и не было :-) Как можно что либо понять в профилировании файла без отладочной информации?
@@DmitriNesterov Там дело в виртуалке поверх виртуалки. Т.к. функция чисто вычислительная, в ней прям нечему тормозить. Если вы делали на C++ wasm поделитесь своими результатами. Т.к. я сейчас "мучаю" Rust, то хочу на нём и wasm еще раз посмотрю
бред, сравнение не в тему
А какое сравнение будет в тему? Если мы даже json с бэка в несколько раз медленнее получаем. Это при том что я люблю c#, а что вы у слышите не от заинтересованного человека? Можете свои преимущества написать - тут я сравнивал производительность, причём посмотрите сравнение .net vs node.js у меня из последних роликов.
У меня вышло так (один из прогонов):
с aot - json 743 / обработка 137 / отрисовка 1888
без aot - json 2665 / обработка 154 / отрисовка 2569
Проверял запуская запаблишеный хост в релизе. По aot видна разница во времени вычислений, отрисовка долгая скорее всего из-за интероперации с js-овскими интерфейсами для канваса. Я не смотрел пример с англуляром, но как я понял основная часть работы тут вообще никак не использует ангуляр - это просто чистый нативный js и браузер - десериализация json-а и работа с канвасом.
Получение и десериализация json-а в ангуляре работает через дефолтные механизмы браузера которые работают на нативном коде браузера, без виртуальных машин с небольшими обертками от ангуляра (httpclient service). Как это работает в blazor - я лично не очень понимаю, но вполне возможно что десериализация json-а идет кастомным кодом, а не нативным- отсюда проблемы с производительностью.
Еще по коду отрисовки в C# - я опять же понятия не имею как оно там в итоге работает - но меня смущает вездесущий await - я понял что там без него никак, но у меня почему то есть дурацкая мысль что возможно await там делает что-то типа setTimeout(..., 0) - и переносит вычисления отложенно на следующий прогон event-loop-а в браузере. А т.к. там подобных вызовов много, то это может долго работать. Но это предположения, врядли оно так
Я кстати про то что отрисовка дико тормозная даже не акцентировал, а то что даже json с Бека медленно получается, на это обратил внимание. В релизе собирал, там с aot, в дебаге еще медленнее. Тут не blazor виноват, а связка wasm, которая не даёт чуда, получается нужно скопировать память сначала из js, что-то поделать, а потом обратно копировать, но вот все эти копирования и тормозят, а сам wasm не сильно быстрее js, тот же код на чистом c# в 2 раза быстрее js по моим тестам, и это без специальных оптимизаций c#.
В ангуларовском случае можно было бы вынести всю обработку(математику, парсинг json), которая не нуждается в доступе к DOM, в Worker, тогда он будет выполняться в отдельном потоке браузера и теоретически будет быстрее. Тогда разрыв станет ещё более сильным.
Просто парсинг не ускорит вынесение в backgroundworker, т.к. между основным процессом и worker нужно будет передавать данные, а вот расчеты, ускорит
@@Kulibins1 верно я понял, что в видео сравнивали производительность двух вариантов: 1) TS/Angular в браузере и 2) SSR Blazer на сервере?
Хотелось бы видеть результаты сравнения различных вариантов реализации, но на одной стороне, например, в браузере.
Например, на клиенте
TS/Angular vs WASM Blazer.
@@vanmihaylovich не верно. Сравнивался клиентский (браузер) blazor, т.к. северный wasm не использует. В серверном наш c# работает на сервере, а изменения отправляются через single в браузер. Мне не интересен серверный вариант (уже несколько раз объяснял почему).