Спасибо за такой материал. Очень нужное сравнение 👍

@Kulibins1

2 жыл бұрын

Хотел сравнить, вот получил...

Спасибо за информативное видео. Как раз искал что-то подобное и в топе поиска кликнул на видос не раздумывая)

@Kulibins1

2 жыл бұрын

Всегда пожалуйста 😊

Весьма годный, полезнейший контент на самом деле. Большое спасибо!

@Kulibins1

2 жыл бұрын

Всегда пожалуйста 😊

по больше б таких нормальных сравнений с разными технологиями и фреймворками)

@Kulibins1

2 жыл бұрын

Будет еще

@arrrryyy

2 жыл бұрын

Кроме скорости загрузки огромной страницы никаких других сравнений. Если у тебя сшарп программисте ты можешь сэкономит огромное деньги с razor, blazor, blazor server I xamarin.

Спасибо, полезное видео!

@Kulibins1

2 жыл бұрын

Всегда пожалуйста 😊

вообще классно. интересно было

@Kulibins1

2 жыл бұрын

пожалуйста

Спасибо. Хорошее сравнение. Только думал посмотреть на blazor) лучше на ангулар)

@Kulibins1

2 жыл бұрын

Код blazor просейший, с точки зрения программистат всё красиво и понятно. Но результат.... json 5.5 Mb

@Kulibins1

2 жыл бұрын

Исходники в описании

Спасибо! Александр, а покажите хотя бы кусок той портянки с данными, из которой вы рисуете на канвасе?)

@Kulibins1

2 жыл бұрын

github.com/AlexanderZhelnin/blazor-webassembly/blob/main/wwwroot/sample-data/primitives.json

@dasvas9383

2 жыл бұрын

@@Kulibins1 Скажите, а эти данные выгружаются из какого то редактора?

@Kulibins1

2 жыл бұрын

@@dasvas9383 да из моего 🤣 ГИС Сфера

@dasvas9383

2 жыл бұрын

@@Kulibins1 Аахах)) Ну значит правильно подумал)

А если попробовать Блейзор с АОТ сбилдить (кажись запаблишить надо будет)?

@Kulibins1

Жыл бұрын

Так тоже пробовал. Не помогает. Сама суть трансляции через was тормозит

А AOT компиляция была? Там вроде бы можно как-то умудрится оптимизировать Blazor WASM. И было бы круто ещё сравнение с Blazor Server

@Kulibins1

Жыл бұрын

Конечно была, оба проекта на гитхабе можно проверить. Вывод => мёртвые пчёлы не жужжат

@enter0prise

Жыл бұрын

@@Kulibins1 На гитхабе в файле проекта не видно необходимого ключа RunAOTCompilation/true. Да и было бы круто сравнить цифры обеих режимов.

@Kulibins1

Жыл бұрын

@@enter0prise когда делал на компе крутил и так и этак. Не помогает. Тут меня бесит что загрузка с бэка обычного json в разы медленее. Даже не хочется дальше этим заниматься - реально тупиковая ветвь. У меня довольно ресурсоёмкие проекты, и хоть я люблю c#, но лучше я на Angular фронт буду делать, который будет реально шустрым.

@enter0prise

Жыл бұрын

@@Kulibins1 где-то на хабре писали, что в хромиуме парсинг JSON чудным образом работает быстрее, чем создание объектов из литерала) с этим сложно тягаться, учитывая, опять же, копирование. Можно убрать затраты на рефлекшн с прегенерацией маппинга, но это вряд ли драматически изменит затраты. У вас интересный тест вышел, по самым больным местам блейзора)

А какой рантайм в блейзоре используется? Надеюсь, что в dotnet 6 и dotnet 7 это исправят

@Kulibins1

2 жыл бұрын

Тут 6-й. Не исправят 🤔

@artursveshnikov7668

2 жыл бұрын

@@Kulibins1 жаль, а по синтаксису очень вкусно выглядел. Есть вроде как альтернатива opensilver комьюнити недавно зарелизили. Это как бы сильверлайт c#, dotnet и xaml но реализован на webassembly. Интересно было бы взглянуть в сравнении, если будет возможность. Ps. Спасибо за ответ

@Kulibins1

2 жыл бұрын

@@artursveshnikov7668 сам web assembly. Не имеет огромного преимущества пред js, а тут нужно сделать виртуальную машину, которая будет по верх него работать, замедление чудовищное. Тут даже если на C писать, код часто медленнее js, я тесты привел. Сам думал что идея интересная, но пока они сам веб ассембли, не сделают действительно быстрым...

@dimitryk8429

2 жыл бұрын

что мертво умереть не может

@artursveshnikov7668

2 жыл бұрын

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

Подскажите, а как вы снимаете себя таким образом, что в заднем фоне у вас ничего не было и остаётся только ваша голова и тело

@Kulibins1

4 ай бұрын

у Nvidia есть такая возможность прога Broadcast

А можно пример исходников алгоритмов, которые используются для построения карты? Они меня прям в сердечко поразили)

@Kulibins1

2 жыл бұрын

Алгоритмы простейшие в этом примере, все алгоритмы в моём большом коммерческом проекте. вот исходники того что показываю в видео github.com/AlexanderZhelnin/blazor-webassembly github.com/AlexanderZhelnin/angular-map

Я на Blazor только с формами работаю, без графики. Всё нравится. Но, вероятно, чем сложнее фронтенд, чем больше графики, тем ситуация будет печальнее.

@Kulibins1

2 жыл бұрын

На самом деле тут дело не в графике, а в том что .net через wasm значительно тормознее чем обычный js. И да тут нагруженные страницы приходится оптимизировать, что будет на блейзоре...

В ангуларовском случае можно было бы вынести всю обработку(математику, парсинг json), которая не нуждается в доступе к DOM, в Worker, тогда он будет выполняться в отдельном потоке браузера и теоретически будет быстрее. Тогда разрыв станет ещё более сильным.

@Kulibins1

2 жыл бұрын

Просто парсинг не ускорит вынесение в backgroundworker, т.к. между основным процессом и worker нужно будет передавать данные, а вот расчеты, ускорит

@vanmihaylovich

Жыл бұрын

@@Kulibins1 верно я понял, что в видео сравнивали производительность двух вариантов: 1) TS/Angular в браузере и 2) SSR Blazer на сервере? Хотелось бы видеть результаты сравнения различных вариантов реализации, но на одной стороне, например, в браузере. Например, на клиенте TS/Angular vs WASM Blazer.

@Kulibins1

Жыл бұрын

@@vanmihaylovich не верно. Сравнивался клиентский (браузер) blazor, т.к. северный wasm не использует. В серверном наш c# работает на сервере, а изменения отправляются через single в браузер. Мне не интересен серверный вариант (уже несколько раз объяснял почему).

WASM должен выжить! и победить!

@Kulibins1

2 жыл бұрын

Да я не против, только он должен быть действительно быстрым + либо уметь то что умеет js, либо передача информации между js и wasm должна быть более гибкая и быстрая, а то через эти буферы как по мне очень не удобно

А что же тогда последние пару лет все вокруг топят за server side rendering если это прошлое?

@Kulibins1

Жыл бұрын

Вопрос. Кто топит? Может это последние попытки систем которые только и умеют серверный рендеринг? Вот из Angular за ненадобностью его убирают. Да и какие преимущества у серверного рендеринга?

на нет 8 или 9 не пробовали перезапустить?

@Kulibins1

12 күн бұрын

@@silaevanton1844 на 8 пробовал, ссылки на исходники в описании, так что можно и на 9 запустить.

Как дела обстоят спустя год?

@Kulibins1

Жыл бұрын

Не проверял. А что координально поменялось? Dotnet через wasm хорошо работать не будет. Недавно слышал аналогичную проблему от golang, у них есть трансляция в js и wasm, так вот js версия быстрее. Я как большой любитель c#, если бы хоть шанс был бы, то не стал бы так ругать blazor, но мертвые пчёлы не жужжат 🥺

Я делал подобный тест 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 выйдет

@TheBesogon

8 ай бұрын

По результатам тестов Такахиро можно увидеть, что webAssembly проседает в основном на тестах вычисляющих double значения. С int там всё гуд.. так что +- скорость зависит от применения webAssembly.. например для тяжелых вычислений самое оно,

@Kulibins1

8 ай бұрын

Как уже писал: дело еще в том что виртуальная машина .net поверх wasm работает.

@Kulibins1

8 ай бұрын

@@TheBesogon да в моих вычислениях были double, но пробовал и single - ничего не поменялось

@Saveaaa

5 ай бұрын

А пробовали аот ? Должно быть ощутимо быстрее в теории

рано еще на блейзор переходить? реакт + asp net core остается лидером??

@Kulibins1

2 жыл бұрын

на беке я .net core, а вот фронт Angular. Angular очень близок к тому что мы делаем на бэке, очень близок к wpf, он гораздо мощнее чем React. Но как уже говорил кому что нравится 😋

а если протестировать на .Net 8?

@Kulibins1

5 ай бұрын

Позже проверю

Интеропы из WebAsm в JS и обратно - очень медленно работают. Если делать на WebAsm - то делать надо все на вебасм, без канвасов, а используя Blazor библиотеки, тот же SyncFusion к примеру - тогда норм будет.

@Kulibins1

Ай бұрын

Как раз я оценил именно без туда-обратно, а вот если ещё и туда-обратно вообще катастрофа. Может если на C или Rust написать wasm будет получше, но тут всё плохо

@websystema

Ай бұрын

@@Kulibins1 благодарю за ваше исследование - было интересно.

А что тут удивительного если в wasm нет jit? Надо было пробовать с AOT компиляцией хотя бы. И опять же - blazor никогда не будет быстрее на клиенте, пока ему надо будет дергать JS при работе с DOM.

@Kulibins1

2 жыл бұрын

Я тут разделил вычисление и отрисовку, тут даже вычисления не конкурентоспособны. Что бы и другие видели на примере, что смысла пока в blazor нет. И как я сказал проверял после публикации в релизе. Простой запуск намного печальнее

@fgdfgh

2 жыл бұрын

@@Kulibins1 Ну имхо для каких то внутренних приложений, которые у вас были на формах/вебформах вполне вариант. А так старый моно рантайм, кучу интеропа с JS(вот например когда вы используете канвас) - все это даёт печальную производительность. Ещё производительность в разных браузерах кардинально различается. Если в хроме скажем всё ещё более или менее, но попробовав тестовый проект в файрфоксе можно инсульт словить 😄

@Kulibins1

2 жыл бұрын

@@fgdfgh я предлагаю перейти на любой нормальный современный framework: Angular, React, Vue. Мне Angular нравится, он ближе к wpf, и очень хорошо ложится на все что вы знали. Я winforms не занимался с .net framework 3.0, но думать что код форм через обертку будет летать на blazor, по моему мнению - утопия.

Понятно, что WASM будет просвживаться на интеропе. Было бы интересно попробовать рисовать в память, а потом уже готовую картинку копировать в JS.

@Kulibins1

Жыл бұрын

Про скорость рисования я в этом видео даже не сравнивал. Тут простая математика ( кстати она же используется в виде для сравнения с node.js) и blazor медленее чем js 😕 мне хотелось обратного, но есть как есть.

@enter0prise

Жыл бұрын

@@Kulibins1 Честно говоря, я еще толком код не смотрел, но так понимаю, что в обоих вариантах рисуются примитивы на канвас, т.е. каждый раз доыгается интероп в JS. Если же свести эти вызовы к минимуму, передав однажды просто кусок памяти, может получиться не так уж сильно проигрывать)

@enter0prise

Жыл бұрын

@@Kulibins1 Пока wasm не умеет управлять памятью из JS (нет встроенного GC), всегда будет это чертово копирование на границе. Чем больше данных, тем печальнее цифры.

@Kulibins1

Жыл бұрын

@@enter0prise нет, там я даже не сравниваю рисование примитивов, а сравниваю математику преобразования координат, каждый вызов рисования это возврат к js а это переход ооочень медленный, так вот просто преобразование координат получается медленнее чем в js. При том что если делать этот же код на бэке с c# то он будет на 40-50% быстрее. Но пересылка информации это тоже время, которое просто съест весь профит

@enter0prise

Жыл бұрын

@@Kulibins1 Боль) если математика проседает, то все безнадежно пока.

Код выложил. Писал быстро, комменты почти не ставил, так что сори.

О какой версии WASM идет речь ?

@Kulibins1

Жыл бұрын

Тут смотрю, то что с blazor с .net6 на самом деле тут все точно так же нужно оценивать накладные расходы что бы передать данные в was, а потом получить - это очень даже не бесплатная операция. И на этом примере видно что одна виртуалка поверх другой виртуальной машины хуже чем js

@vas_._sfer6157

Жыл бұрын

@@Kulibins1 WASM работает на V8 или SpiderMonkey. Ну и с чем не могу не согласиться. Жирные языки в WASM это какое-то извращение

@Kulibins1

Жыл бұрын

@@vas_._sfer6157 да как оказалось и другие аля golang так же в wasm медленее.

@vas_._sfer6157

Жыл бұрын

@@Kulibins1 Goland тоже имеет жирный рантайм. Причем очень жирный. Да там нет виртуальной машины, но там очень хитрый сборщик мусора со своими взглядами на память. Тут нужно смотреть в сторону Rust или C и C++. Хотя Rust здесь однозначный фаворит.

@Kulibins1

Жыл бұрын

@@vas_._sfer6157 Цель этого видео показать, что Blazor не жизнеспособен 😔

вот еще сравнение) но здесь wasm(C++) показывает себя лучше github wasm-3d-animation-demo

@Kulibins1

2 жыл бұрын

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

@qweyn

2 жыл бұрын

@@Kulibins1 там есть ссылка на демку веб сайт и можно тестировать js и wasm увеличив количество скелетов, ещё показывает фпс память пинг

@Kulibins1

2 жыл бұрын

@@qweyn посмотрю

У меня вышло так (один из прогонов): с 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-а в браузере. А т.к. там подобных вызовов много, то это может долго работать. Но это предположения, врядли оно так

@Kulibins1

2 жыл бұрын

Я кстати про то что отрисовка дико тормозная даже не акцентировал, а то что даже json с Бека медленно получается, на это обратил внимание. В релизе собирал, там с aot, в дебаге еще медленнее. Тут не blazor виноват, а связка wasm, которая не даёт чуда, получается нужно скопировать память сначала из js, что-то поделать, а потом обратно копировать, но вот все эти копирования и тормозят, а сам wasm не сильно быстрее js, тот же код на чистом c# в 2 раза быстрее js по моим тестам, и это без специальных оптимизаций c#.

"нативное" всегда быстрее, но не всегда удобнее... webgl для отрисовки вроде предпочтительнее, но рисовать на канве через несколько оболочек, уфф

@Kulibins1

Жыл бұрын

Я тут даже не сравнивал именно рисование. Тут в Blazor медленно именно сам расчёт, получение с бэка обычного rest запроса, причём ооочень медленно. Если настоящий c# на бэке минимум на 40-50% быстрее в этой же задаче чем например node.js, то Blazor на несколько порядков медленнее чем простой js код (сравнение . net vs node.js смотри в моих последних роликах)

Вот интересно, я делаю на blazor мнемосхемы работающие в реальном времени, которые работают 24/7, тысячи анимированных графических элементов (canvas) и ничего не тормозит, и что я делаю нет так)) Не верьте таким обзорам, когда руки и голова на месте, будет и результат отличный.

@Kulibins1

9 ай бұрын

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

Не все время такой большая страница. Скорость у тебя наверно не больше чем 10. В США почти у всех скорость 100. После изначальной загрузки работает быстрее. Если сшарпом только работаешь то блазор спасает. В некоторых случаях можешь фронтенд на Джаваскрипт писат или часть. Сервер никуда не пропасть. Скорость интернета больше есче намного безопасно.

@Kulibins1

2 жыл бұрын

У меня запущено локально 🤣 и сервер и клиент. Тут явно дело не в скорости соединения. Тут проблема в том что виртуальная машина .net работает поверх виртуальной машины wasm. Если запускать просто c# то код минимум 2 раза быстрее чем js, но вот c# поверх wasm это дикий тормоз. Современный веб и так высоконагруженный и с моей точки зрения для серьёзных web приложений blazer не применим.

@arrrryyy

2 жыл бұрын

@@Kulibins1 Понятно. Всё таки карта большая по объёму. Есть много сайтов только на блейзер и 90% их так не захлебнутся как твоя карта. CNN и другие большие сайты на Джаваскрипт тоже буксуют. Джаваскрипт вместе с с# тоже один на голове второго.

@Kulibins1

2 жыл бұрын

@@arrrryyy на самом деле не очень и большой json, и его обычная загрузка очень тормозная.

Не знаю, этот блейзер мне напоминает силверлайт и его ждет такой же конец :)

@Kulibins1

Жыл бұрын

Силверлайт быстрее работал

А при чем сдесь angular, скорее typescript

@Kulibins1

19 күн бұрын

причём тут TS ? ts всё равно в js преобразуется, тут именно плахая работа wasm, т.к. виртуалка поверх виртуалки, как результат обычный js быстрее

@hap123qwe

19 күн бұрын

@@Kulibins1 в итоге конечно js, в ts в плане написания кода

@Kulibins1

19 күн бұрын

@@hap123qwe код максималтно идентичный и там и там

А ну да платежи те же ты будешь без серва принимать подумаешь спиздят всё

@Kulibins1

5 ай бұрын

Пишите понятнее. а то мысль без контекста.

Профайлинг в релизе? А что, так можно было? Мы, просто, на плюсах пытаемся до вас дотянуться

@Kulibins1

5 ай бұрын

Не понял вопроса

@DmitriNesterov

5 ай бұрын

@@Kulibins1 Здравствуйте! А там вопроса и не было :-) Как можно что либо понять в профилировании файла без отладочной информации?

@Kulibins1

5 ай бұрын

@@DmitriNesterov Там дело в виртуалке поверх виртуалки. Т.к. функция чисто вычислительная, в ней прям нечему тормозить. Если вы делали на C++ wasm поделитесь своими результатами. Т.к. я сейчас "мучаю" Rust, то хочу на нём и wasm еще раз посмотрю

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

@Kulibins1

2 жыл бұрын

Не согласны - опровергните. А то что blazor через wasm работает в разы медленнее очевидно. Наоборот я хотел что бы результат был обратный

WebAssembly не имеет доступа к DOM. Глупо пытаться через него рисовать на DOM! WebAssembly совсем не для этого предназначен!!! Готовь картинки на WebAssembly, а выводи выводи свои готовые картинки через js. Не нужно сравнивать WebAssembly в том, для чего он не предназначен! Сравни не доступ к элементам DOM, а нормальный математический алгоритм на C# c компиляцией AOT и увидишь трехкратное преимущество. При этом ещё и уйму времени сэкономишь переиспользованием серверных библиотек.

@Kulibins1

Жыл бұрын

В моём примере нет рисования именно в websssembly, я делал лишь подготовку данных. И получается у blazor очень медленно

@Alexander.Glazkov

Жыл бұрын

@@Kulibins1 Я вам говорю - математика в разы быстрее работает. Вы компиляцию AOT из IL в WebAssembly использовали? Наверняка нет. Тупо в режиме интерпретации IL через тормозной mono'вский интерпретатор запустили и удивляетесь... Надо уметь применять технологию, а уж потом смешить весь интернет своим кликбэйтным "хейтом". А то у вас получается как в басне "Мартышка и очки"...

@Kulibins1

Жыл бұрын

@@Alexander.Glazkov я уже говорил что запускал так. Исходник на гитхабе возьмите и проверьте в каком угодно режиме

@Kulibins1

Жыл бұрын

@@Alexander.Glazkov очень медленно работает передать данные и получить обратно результат

бред, сравнение не в тему

@Kulibins1

Жыл бұрын

А какое сравнение будет в тему? Если мы даже json с бэка в несколько раз медленнее получаем. Это при том что я люблю c#, а что вы у слышите не от заинтересованного человека? Можете свои преимущества написать - тут я сравнивал производительность, причём посмотрите сравнение .net vs node.js у меня из последних роликов.

Какой сложный проект. Честно говоря, просто было бы лень усилий для этого клипирования и так далее. Мое уважение, Александр.

@Kulibins1

Жыл бұрын

это кусок из моего существующего ГИС Сфера2. Только это лишь часть расчётов, самые ресурсозатратные это отображение подписей, когда система атоматически определяет наилучшее положение текста, да ещё так что бы тексты не пересекались. Но в этом примере этого нет, тут всё просто 😊

@user-yq2mj6mq3e

Жыл бұрын

@@Kulibins1 благодарю за пояснения. Вы молодец ✊

нужен ретест на .нет8

@Kulibins1

8 ай бұрын

Он как раз вышел. У меня будет неделя отпуска в конце ноября, сделаю ретест (это не так долго, как материал с нуля делать 🤣) Результат выложу на канале телеги, а если будет - вот прям интересные результаты, то сделаю видео.