А почему код однопоточной ноды написан полностью в блокирующие стиле? Функции хендлера синхронные, блокирующие, fs readfile синхронный. Типа потому что на net код тоже синхронный? Чтоб честно было? Тогда чтобы было честно , может тестировать на системе с одним ядром (в контейнере).
Вы асинхронную Ноду заставили против ее природы работать синхронно, а потом говорите, что .net быстрее. А если раскидать Ноду по потокам, которые у нее есть и дать работать асинхронно, каким окажется результат сравнения?
@@Kulibins1 Читать файл синхронно, потом запустить сервер, в запросах к которому тоже читать файл синхронно - это как бы синхронно. Плюс тяжелая математическая операция, которую в реальном проекте вынесут в отдельный поток, дабы не блокировала текущий. Плюс некоторое количество вещей в коде, которые в реальных проектах так не пишут. Плюс Ваши утверждения о типах чисел в Ноде, основанные явно не на документации к V8, плюс утверждения о многопоточности, которые не соответствуют действительности. Это не сравнение производительности в реальных условиях. Это сравнение теплого с мягким. Они разные и работают по разному. Корректные тесты должны максимально учитывать преимущества тестируемых систем, чего в данном случае нет.
@@albalyu файлы и там и там читаются синхронно, и этот небольшой файл уже в кэеше, и при тесте выдаёт максимальное число которое вообще возможно и там и там (упёрлось в канал). Ваши предложения странноватые, вы предлагаете аналог webworker использовать? Так на внутреннюю пересылку потратится больше времени. И тогда я включу потоки для c#, как думаете какой будет результат?
на node js у вас initial connect занимает 300ms(видимо косяки в настройке сервера). само же вычисление - waiting for server respond занимает 20ms на node js и около 30ms у C#
а бэк может по разному настроен из коробки? нужно инфа в количество потоков, процессов, память хз.. предлагаю в эту сторону еще посмотреть слишком большая разница чет в производительности.. либьюви количество памяти-потоков.
Да все из коробки. Характеристики компа зеон 12 ядер, 24 потока, памяти 64 Gb. Если смотреть загрузку памяти, то она копеечная там что-то 500 Mb. Самое интересное процессор тоже не загружен, при тесте больше всего сам jmeter взял, но всё равно общая нагрузка всего не превышала 25% проца, т.е. как бы сказать что мол node в одино ядро работала, а .net нагрузил все ядра, то тоже нет. У меня есть видео про моё рабочее место там характеристики компа видно подробно.
1) Node js вроде уже 100 лет в обед как поддерживает многопоточность, разве нет? 2) Для тяжелых вычислений есть возможность писать на Ноду модули на Расте или C++.
Когда-то давно был у меня проект на VB (Легаси), а сложные вычисления я писал на ASM с использованием mmx и sse. Вы предлагаете нечто похожее. Для этого либо вы должны C++ знать, либо должен другой разработчик эту работу сделать. Если вы специалист по C++, то сомневаюсь что будете писать на Js, C++ сник может зарабатывать больше чем Js ник, хотя бы из-за того что их меньше. Разработчиков Rust видел еще меньше, но тесты напишу что бы rust сравнить с c#.
@@nitroexpress9928 ну к c# тоже можно подключить DLL на c++ причем есть mc++ это смесь менеджмент и анменеджмент кода на c++. И даже win api вызывать и кучу других малоприменимых сценариев, например можно openCl (я пробовал)
Если я правильно помню у ноды кластера используются, хз насколько они лучше или хуже чем многопоточность, но я думаю надо было и кластера чекнуть. Плюс мне лично хотелось бы понять насколько сильно нода отстаёт от Шарпа в обычном rest api, так как если париться насчёт ручного управления памятью то можно и весь бэк на golang/rust написать, или на питоне и всё вычисления на сишных dll-ках делать
У автора статьи была просто нода, а так да можно и с клатером сравнить. Но я смотрел и в один поток когда из браузера запрашивал - результат был виден, всё равно .net быстрее, иногда значительнее
В ноде нужно явно делать форки для кластеров, при этом они не сильно помогают в производительности, так как нода по факту работает многопоточно за счет микротасков и ивентлупа.
@@Kulibins1 скачал код из Вашего репозитория, у меня этот /map что на ноде, что на дотнете отрабатывает за 20 +/-2 ms (i5-9600K, Linux Manjaro, .NET 7, NodeJS 18). Откуда такая огромная разница на видео - непонятно. Вы на винде тестили?
@@nitroexpress9928 тестил на Винде. Но не нужно говорить что тут винда виновата и что Линукс в разы быстрее, это не так. Проц у меня зеон. Сколько у вас показал jmeter? Конфигурационный файл вместе с исходниками
То, что Node.js нет многопоточности - это давно неправда (смотреть в сторону модуля worker_threads). К тому же никто на Ноде не пишет реальные запросы в синхронном блокирующем стиле. Это просто неэффективно. Даже в самом начале мануалов для начинающих говорится, что надо использовать асинхронный неблокирующий код. Плюс движок V8, а Нода - это именно V8, для разных типов чисел использует разное внутреннее представление, и если мы переменной присвоили целое, то и обрабатываться она внутри будет как int, а не как double. И только если мы присвоим вещественное число, то переменная поменяет свой тип на тип с плавающей точкой. Прежде, чем что-то утверждать о том, с чем Вы не очень знакомы, хорошо бы посмотреть доки - а вдруг все совсем не так, как Вы себе представляете. Также сила Ноды в том, как она множество запросов, которые обрабатываются асинхронно, а не один за другим. И время их выполнения частично перекрывается. Да и сама Нода со старта работает сразу в несколько потоков и для разных надобностей используются разные потоки. Ничего не имею против C#, но отказаться от всех преимуществ Node.js, а потом утверждать что C# быстрее - это не очень красиво.
Реальное предложение: Вы находите программиста на Ноде с большим опытом (не меня - мне лениво), договариваетесь с ним о функциональности, работу которой хотите протестить и он пишет максимально эффективный код на Ноде, опираясь на годы своего опыта, а Вы на C#, опираясь на годы своего опыта. А потом можно сравнивать. Это и будут одинаковые условия, с моей точки зрения.
@@albalyu я написал полностью идентичный код. Он не максимально эффективен на c# ( максимально эффективен был исходный мой код). Я же просил дать реальные замечания к коду на Js, то пишете что я как-то заблокировал асинхронность/многопоточность Js, то огромный ответ что внутри движка v8 Js number может соптимизироваться до int (хотя все вычисления с double в карте идут и ни какой оптимизатор ничего не делает). В общем не надо голословных утверждений.
@@Kulibins1 Вы не могли написать полностью идентичный код для систем с таким разным подходом к разработке. Уже то, что Нода асинхронная, а Шарп синхронный говорит о том, что работают они по разному, и писать для них надо по разному, а не идентично.. Ваши вопросы ко мне говорят о том, что Вы даже не понимаете проблем Вашего JS кода. Теперь конкретно: Вы сказали в видео, что все числа в JS представляются в виде double, однако это не так, V8 имеет различные внутренние представления для различных типов чисел. Вы сказали, что в Ноде нет многопоточночти - это уже давно не так. Вы написали синхронный блокирующий код для асинхронного сервера и утверждаете, что так и надо. На Ноде так даже джуны не пишут, потому что по рукам получают ). Вы используете сохранение элементов массива каждый раз увеличивая его размер и утверждаете, что это нормально, но такое сохранение данных в массив работает в 20!!! раз медленнее, чем если бы Вы сразу создали массив нужной длины. Для массива размером 10 000 000 элементов время выполнения цикла заполнения элементов значениями будет соответственно 12-15 мс и 250-300 мс на моем компьютере. Разница почти в 20 раз. А Вы говорите, что это не имеет значения. А еще про корректные тесты... На сим разрешите откланяться. А ревьюить Ваш код и предлагать Вам тесты, увольте. Вы и сами можете придумать еще много такого же 'корректного', как и эти.
Пример про фибоначчи в node просто не работает (когда число становится большим js просто возвращает infinity). 3:30 полное заблуждение, так как js однопоточный при выполнении цикла он просто заморозится и не будет ничего дальше выполнять пока цикл не закончится ( shyngy/simple-loop ) - github тут пример рекомендую запустить и посмотреть, еще прочитать про event loop
Про то что число становится бесконечность я знаю, результат же запроса выводиься , в отличии от первоначальной статьи. По поду того что я не прав на 3:30 тут пока я не вывел результат, то функция выполнялась максимально быстро, как только вывел, то всё стало на свои места. Как устроен event loop, я как бы знаю (может не всё, т.к. там оптимизаций вагон и маленькая тележка 🤣 )
@@Kulibins1 про 3:30 и вправду node быстрее, так как он просто не считал до конца, а завершил цикл досрочно. 1. Цикл начался, число фибаначчи постепенно начало увеличиваться 2. в один момент число стало настолько большим что буффер заполнился. 3 цикл прекратился вывелся результат Infinity. “я не эксперт в node но по моим наблюдением все работает примерно так”
@@shyngyskhanbokikhan6782 не смотря на такую оптимизацию всё равно оказался медленнее. И это прогнозируемо. И как тут мне многие пишут что мол ноду не берут на вычислительные задачи, а на задачах где всё в БД упирается и разницы не будет. Я это всё понимаю и говорил что ничего в Js плохого не вижу. Тут обман исходной статьи меня немного вывел из себя 🤣
@@Kulibins1 про event loop в github выше есть два примера, которые показывают когда js игнорирует цикл и продолжает дальше работать, и когда он ждет полного выполнение цикла а потом выводит результат.
Вопрос не по теме, но хочется задать. C#/NET не владею, но слежу из далека. Скажите, с учётом рывка в развитии этих технологий + crossplatform'енность Core, можно ли сказать, что эта связка вполне себе может конкурировать с PHP/Python/Ruby для быстрого создания прототипов в web, да и вообще web-проектов? И хостинг уже не является фактором сложности/дороговизны, т.к. вполне себе можно развернуться на linux?
Можно развернуть на линуксе. И смотря в чем вопрос. Если вы хотите делать фронт, то я не люблю server side rendering и все перечисленное именно его и делает. В .net есть и серверный и клиентский рендеринг, но клиентский рендеринг в .net "тормоз". Я делаю бэк на .net, а фронт на angular. Из опыта обычно потом говорят берите и дорабатывайте прототип до коммерческого использования, поэтому и прототип хорошо бы делать правильно. Вот лично для меня сделать прототип на .net + angular займёт столько же времени как кто-то на PHP/Python/Ruby сделает тоже самое. А может и меньше если еще к этой связке добавить .net + GraphQL + Angular
@@Kulibins1 Понял, спасибо. Просто хотел подтвердить гипотезу, что для нового и при этом даже небольшого проекта можно смело брать .net вместо, например, php + laravel или python + django. Вопреки давним мнениям о том, что .net - это дольше и дороже.
17:16 (с# сервер может отвечать на большое количество запросов): А что если нод джээсовский сервер горизонтально масштабирован, то есть у нас за раз работает несколько инстансов этого веб-приложения. Все равно с# сервер будет отвечать на большое количество запросов чем нодовский?
Уже несколько человек об этом написало, но ведь и сервер .net тоже можно масштабировать горизонтально. Тут именно дело в том что автор исходной статьи утверждал что node.js быстрее .net c#, я показал что это не так.
@@Kulibins1 вот только в рамках одного компьютера кластерный режим ничего не даст Шарпу, а Нода в задачах типа этих бенчмарков становится быстрее в разы.
@@nitroexpress9928 может быть. Но вон запустили в кластером режиме ноду получили, только то что она в картах сравнялась (но я бы перепроверил 🤣) в тесте натуральной сортировке отставание в разы даже с кластером.
Тоже вариант, но даже в один вызов если смотреть, то nodejs медленнее. Для языка js, оно работает фантастически быстро, но против мироздания не пойдёшь в C# структуры (их кстати в большой java нет, а как бы всё делать объектами, то сборщик мусора перегружен), прямой доступ к памяти (пример из натуральной сортировки), всякие span и т.д. Если писать простой код, то node.js может и достаточно. Могу кстати и с финансово технической точки зрения обосновать что многопоток лучше чем кластер (хотя и на .net делаем кластера, но тут их будет избыточно - на проекте не дали кластер к postgre сделать, типа обычная репликация без распределения нагрузки 🤔)
@@Kulibins1 я не шарю в .net core, поэтому закрался такой вопрос, а случайно тот вебсервер, который в C# создается в коде, случайно не использует под капотом какой-нибудь пулл воркеров для обработчиков запросов? Чет уж сильно много разрыв в 30 раз, не могу поверить, что там такой оверхед в ноде
@@PavelAShvedov в 30 раз версии где я использую оптимизации прямого доступа к памяти. Этот код равен тому который был бы на голом Си. Представь что каждое обращение к элементу массива, проверяет а не вышел ли ты за его границы, а в коде с прямым доступом я не делаю таких проверок. И на самом деле это еще не максимум который можно выжать, тут можно было бы использовать simd команды, но сложность кода реско возрастёт и придется писать несколько спец версий, например под arm и x64 (sse ... avx), а я последний раз писал только под первый sse. Сколько даст прироста simd, не знаю, мне пока хватает и моего варианта что быстрее аналогов.
@@Kulibins1 ну если дотнет никак не параллелит обработку запросов, и все дело в такой лютой оптимизации под конкретный кейс, то спорить не буду, но с другой стороны показательность этого бенчмарка тоже крайне субъективная, если хочется в ноде заморочиться, то можно написать решение на том же С++ и подцепить к ноде и вызвать, проблема и подхода с упоротой оптимизацией с С#, и с извращениями с С++ для ноды только в том, что в реальной жизни, в каком-нибудь энтерпрайзе, никто не будет так корпеть над тормозящей функцией, проще поднять еще один инстанс приложения и сбалансировать нагрузку, в 99% проектов имеено так и сделают. Максимум что будут пытаться оптимизировать руками, это запросы к БД, если ОРМ-ка не справляется, так как чаще всего основные тормоза в типовых веб-приложениях именно там, а чем дергать эту бызу данных уже не суть важно, C# там, нода или elixir. Сугубо ИМХО
это же все не важно, разве нет? кто на чем пишет, тот на том пишет :) очевидно что dotnet быстрее, но это не важно очевидно что в nodejs войти проще, но это тоже не важно современные задачи (большинство из них) требуют скорости их решния (именно скорости написания кода), но не скорости выполнения этого кода гораздо важнее вопрос поддержки кода, вот тут стоит призадуматься :) что будет через год? сможешь ли ты взять проект написанный год назад и скомпилировать его сегодня? сколько усилий тебе понадобится? а продолжить разработку и развить проект? я бы наверное из этих соображений исходил
Да я тоже несколько раз сказал что главное качество кода и испоганить можно любую платформу, то что сделано на "лучшей" платформе не гарантирует лучший результат. Но повторяюсь: увидел статью где говорилось что нода быстрее, причем с тестами. До этого видел видео (пару лет назад) где "нодер" просто рассуждал что нода быстрее всего. Первое что приходит в голову (на ноде я не делаю свои проекты) может действительно нода лучше? Сделал тесты - нет не лучше. А так я не настаиваю и давно вышел из возраста холиварщиков, кому что нравится тот на том и пишет.
Это не многопоточность. Я про это сейчас делаю видео. А если в крации это горизонтальное масштабирование сервиса. Есть большая разница, а то мне недавно на собеседовании убеждал соискатель убеждал что в js в браузере если сделать setTimeout это тоже будет параллельная работа. Нужно понимать что это и как оно работает, какие преимущества и недостатки
@@Kulibins1 Из официальной документации ноды: "The node:worker_threads module enables the use of threads that execute JavaScript in parallel". Также, неблокирующий I/O работает засчет libuv, которая, в свою очередь, использует отдельный поток. setTimeout - и правда ничего общего с параллелизмом не имеет. Это асинхронное программирование. Я про это и не говорил
@@grenadier1653 про setTimeout я написал как пример абсурдного заблуждения. Тут тоже самое, потоки в node это на самом деле не потоки, а отдельные процессы. Это не есть плохо, у каждого подхода есть свои недостатки и преимущества. Скоро будет видео на эту тему
Number - это не double из C#. Представление чисел в движке V8 - это весьма комплексная вещь (SMI & Double), которая во многом скрывает реализации под капотом, а сверху еще и JIT добавляет оптимизаций. Учитывая, что явных присваиваний дробных чисел нет, переменная меняется в цикле, то я уверен, что там точно такой же int, как и в C# на выходе будет (вы можете прекрасно раскрутить всё и посмотреть, в какие представления оно раскручивается, как в том же sharplab)
Не нужно придумывать 😉: Обычные числа в JavaScript хранятся в 64-битном формате IEEE-754, который также называют «числа с плавающей точкой двойной точности» - это из документации
@@Kulibins1 гуглите в сторону SMI (Small Intergers) в движке V8, будете ОЧЕНЬ сильно удивлены. а по поводу реализации стандарта IEEE-754 - SMI никак ему не противоречит от слова совсем
@@ilyachursin7369 ну тогда node еще медлее, если она проиграла честному double. Кроме того в моём примере с картой, там все вычисления с double и их ни как не оптимизируешь. И т.к. их не мало разница в 5 раз. В общем в моём утверждении что number = double есть возражения?
А то, что node.js проигрывает - оно и понятно. Числадробилки - это явно не тот бенчмарк, в котором nodejs сильна :) да и приминительно ко всем тестам, явно оно будет проигрывать шарпам. Тут как бы классические холивары на тему - А ЧТО ЖЕ БЫСТРЕЕ (ирония на тему - пишите на asm, там уж точно быстрее всего)
В видео про натуральную сортировку у меня были варианты. Тут именно была цель показать что с оптимизацией будет огромная разница. Теперь вот хочу с Rust сравнить 🤣
Сейчас уже не будет никакой разницы (я проверял). В C# довольно хорошая оптимизация. Есть неочевидные способы оптимизации кода, но они не связаны с unsafe.
Хоть на PHP можно и делать web api, но в основном делают серверсайд рендеринг приложения, а этотс моей точке зрения уже не имеет смысла. Кроме того интерес к PHP снизился очень сильно и вероятно останется только на Легаси проектах. В общем сомневаюсь что кто-то из новичков сейчас начнёт его изучать. Поэтому даже если увижу что кто-то скажет что PHP быстрее, то я посмеюсь и не буду "опровергать". Тут от сравнения с js словил замечаний, то тесты (которые из статьи) не те, то мол нода многопоточная (это не так, народ путает отдельные процессы worker thread с потоками - запишу про это видео) то кластер не запустил, то еще что-нибудь. ПРОТИВ НОДЫ НЕ ИМЕЮ НИЧЕГО ПРОТИВ, вполне рабочая вещь.
Глянул репозиторий для С#. Не увидел включенным ServerGC ни в проекте ни через рантайм конфиг. Может стоит через environment variable, но если тесты были с GC in Workstation Mode, что скорее всего и было, иначе на 100 процентов бы загрузил проц, то стоит врубить серверный и перепроверить))
Да запускал в десктопном режиме. На работе автоматом собирается докер образ уже под серверное применение и я это упустил при запуске. Обязательно перепроверю
@@Kulibins1 я не о приоритетах. Насколько я понял ваш тестовый клиент имитировал паралельных клиентов. В этом режиме очень важно распараллелить сервер. В nodejs это нужно делать в явном виде, чего небыло сделано. Если C# распараллеливает по умолчанию то ваше доказательство неверно.
@@user-0xDEEDBEEF там и одиночные запросы на .net быстрее если они хоть что-то реально делают. Уже комрад нодер запустил ноду в кластере и сравнил. У него похоже упёрлось в пропускную способность на Фибоначчи, а вот тест с сортировкой всё равно в разы быстрее на c#. Как бы Обалденно не оптимизировали Js (а они реально сделали практически чудо) c# быстрее. Кстати я тут подумал и тесту карты на Js я подыграл, т.к. по хорошему раз я с точками в c# работаю со структурами, то в Js я должен был использовать объекты, но я переписал математику что бы не было этих объектов, работа была только с массивом number
@@user-0xDEEDBEEF каждый под в кластере стоит денег. Например у нас на каждый cicd-шники еще 0.3 ядра вешают типа на обслуживание + балансировщик для кластерера из ноды. А эти вопросы я даже не сравнивал 🤣, С учетом что и в однопотоке c# быстрее.
Node.JS он не про скорость и не про оптимизацию, он про business needs. Когда хочется иметь команду, в которой бэкендеры и фронтендеры хотя бы частично взаимозаменяемы и какие-то наработки использовать и на фронте и на бэке. Тогда и мобильные приложения можно делать на React Native - вообще красота!
Да я ж что против? Еще раз увидел статью где сказано что нода быстрее, решил перепроверить. Вот результат. А так да если есть хороший разработчик js, то ему бэк легче написать на ноде чем учить что-то другое. И как я сказал скорость js по сравнению что было раньше очень хороша и для многих задач её за глаща. Но вот лично у меня есть задачи где нода ни как не справится, это кстати не обязательно вычислительные задачи, например общение с оборудованием по низкоуровневым протоколам. Ну и вычислительные задачи, особенно со специальной оптимизацией на c# быстрее. Кстати кто знает на доде есть реализации DI (для фронта есть в Angular, а для бэка?)
в таком говностартапе я бы никогда в жизни не стал работать, если аргументом выбора ноды является "один язык на фронте и бэке". многие фронтендеры даже жс экспертно не знают из-за формошлепства, а их еще на бэкенд пускают
Есть подозрение что исходная статья просто развод, примерно как в анекдоте про негров и баскетбольный мяч, сколько уже таких было, и сколько еще будет ... И хотя результат очевиден заранее, но разбор полезен и интересен. Еще интереснее было бы добавить Java, возможно еще что-то новомодное, типа Go или Dart. Ноду корректнее сравнивать в PHP и Python, хотя последний вероятно будет в аутсайдерах.
@@vas_._sfer6157 может и есть, только тут уже скорость разработки упадёт и стоимость сопровождения увеличится. И нужно тестировать, что бы сказать на сколько разница. Может кто сможет мои тесты переписать, для сравнения?
@@Kulibins1 Ну не знаю. Непонятно с чего она вдруг скорость разработки должна уменьшиться. Да и фреймворков уже полно, нет проблемы ни с чем. Единственное проблема - это относительно долгая скорость компиляции для больших проектов - но это фиксится разбиением проектов сначала просто на крейты, а потом и на микросервисы, если они нужны.
Отличное сравнение 👍 + За нодой что на фронте и бекенде используют один язык. Хотелось бы увидить сравнение выдачи через REST API, так в практике это то что используют. Лично сам я предпочитаю C#.
@@ЭдуардКузнецов-ы7у У Blazor как бы 2 режима серверный рендеринг и клиентский. Смысл в серверном рендеринге не вижу, даже из Angular его выпилили. А клиентский, через wasm даже с бэка запрос (увесистую json-ку) получает в разы медленее чем обычный js. Я после этого не стал глубоко изучать документацию по Blazor, т.к. смысл изучать, то чем не буду пользоваться, хоть и .net + c# дольше всего занимался.
Тут смотрел по тестам, если ничего не менялось во вне, и результат не возвращался, то скорость такая, как будто-то выкинул. Как только возвращаешь, то скорость резко снижается
Спасибо за интересное сравнение. Интересно было бы еще сравнить их в облаке в условиях когда они создают одинаковую нагрузку на сервера, так будет совсем честно и приближено к реальности. Понятно что шарп быстрее, но будет ли он настолько же быстрее в таком случае )
@@vasiliigodunov1746 зачем wcf? Есть grpc, есть шина. Я уже отказался от wcf давно. Да и то когда для wcf сделал свой сериализотор, то и wcf был быстрым
@@Kulibins1 я тоже думал, что WCF был быстрым, но тесты показывали обратное. В нём были большие потери на этапе применения всех его замечательных декларативных политик. К каналам претензий нет.
@@Kulibins1 ну а если взять тот же grpc и примотать к нему аутентификацию по SSL сертификату, то замечательная технология Google превращается в шлак от MS :) MS гениально умеет добавлять проблемные зоны в транспортные протоколы
Приятно, когда любимая технология побеждает :) Вообще, давно уже известно, что любые статьи с тестированиями больше говорят не об участниках тестирования, а о составителе тестов. Какой специалист - такие и тесты. Очевидно, автор статьи - так себе специалист
Странно что у автора статьи и в профиле написано .net developer. И тесты притянул он за уши, и если бы повторно их запустил даже на своей программе, они бы показали другие результаты. Node.js тоже хорошая технология и очень даже применимо, но по сложности написанию кода как минимум не проще чем на c# написать (вон в его де примере кода на c# меньше нужно чем на js) а результат у . net лучше. Тут говорят про кластер, но клатер тоже вносит свой минус как в скорость, так и в стоимость, хотя если нужно на любой платформе можно кластер сделать.
@@Kulibins1 насколько я понимаю, node cluster делает ровно то, что у .net идет "из коробки" - многопоточность. Ради интереса можно пойти другим путем - урезать thread pool у .net до одного свободного потока для равных условий
@@Kulibins1 Причем тут медленнее или нет. Как будто если весь мир не построен на .Net то значит все вокруг идиоты :) У питона из коробки не будет асинхронщины, вроде как. Или, например, нет у вас питонистов сейчас в пуле разработчиков в данной компании, это что теперь, проект останавливаем и идем питонистов искать? Не всегда и везде нужна максимальная скорость, а там где нужна можно и го с растом с таким же успехом взять.
@@dmitriyobidin6049 В нашей компании есть похоже все, и питонисты в том числе. Я все к тому что скорость разработки везде +/- одинакова если вы специалист, то одинаково быстро и качественно напишете на своей платформе код, так же как и другой специалист на своей платформе, Но если на одной платформе код быстрее работает, больше запросов обрабатывает, меньше ресурсов потребляет, то как бы это же лучше? 😉
@@dmitriyobidin6049 по многим другим критериям .net однозначно хорош. Например и игры делат (unity), и бэк и десктоп (хотя я от отказался, до этого много лет занимался wpf), фронт вон тоже делают (но тут я считаю что пака перспективы плохие). Код довольно надёжный (сборщик мусора ), быстрый, в некоторых случаях ультимативный и сравним с кодом на С (Rust не занимался с ним не сравниваю), всё что можно и нужно есть в библиотеках (справедливости ради сейчас во всех современных платформах все есть). Работает на всех операционках (многие наверно думают что только по виндой?, так нет под любыми линуксами тоже работает). Язык C-подобный перейти на него нет проблем ( вон все рассказывают какой питон простой, а на деле, он по сложности не уступает другим языкам). Сама платформа постоянно развивается (под ту же ноду, насколько знаю как- притихло). Какие еще у вас критерии?
да можно хоть что сделать на чём угодно. но если вы хотите приблизится реалтайму, то js довольно плохо, и .net плохо, но во много раз лучше в этом плане.
Посмотрев код автора, захотелось его развидеть. Такое ощущение, что автор до этого момента писал JS только для браузера… о каком объективном сравнении может идти речь, когда код, написанный как под браузер, сравнивается с кодом, написанным под бек.
@@NickAlexandrov так там изначально код из статьи, то что я добавил 2-а теста, это с подготовкой данных для отрисовки карты, и код сравнения строк для натуральной сортировки. В тесте Фибоначчи сделал вывод значения вместо "done". Ничего координально в запуске не менял, т.к. потом скажут что из-за того что на экспресс поменял или еще что - не соответствует тому что в статье было. И просто интересно что конкретно не нравится?
@@Kulibins1 как минимум то, что в любом запросе, даже когда req.url = “/” обрабатываются и остальные if, а также создаются объекты rect, pr и строки STR1, STR2. Затем readFileSync моветон так как блочит eventloop. В /map тяжелые stringify и build выполняются в каждом запросе, хотя в этом нет смысла, затем в натуральной сортировке к строке прибавляется число и циклы while блочат eventloop пока не вернут результат. Ещё обилие генераторов прям из мира фронта всю производительность кладет на лопатки.
@@NickAlexandrov Пробовал применить express ни какой разницы. все константы вынес из функции - это дало +1.5 вызова в секунду т.е было 96.3 стало 97.8 запросов в секнду . соотношение это ни как не поменяло. И выводы ни как не изменились. Жду еще недостатки, которые изменят картину.
Было бы интересно проверить заодно низкоуровневую JS оптимизацию в виде asm.js. Механизм старый и потому новомодный синтаксис не понимает (да и с точки зрения ES5 выглядит очень не очень), но использует AOT компиляцию и позволяет использовать вычисления с целыми числами, что в сравнении с нативным кодом на double позволяет добиться ускорения в 5 раз (если сравнивать с целыми в нативном режиме то всего в ~3 раза). Правда для кода вроде чисел Фибоначчи нужно использовать рандомизацию, иначе срабатывает какой-то встроенный кэш результатов. В node.js вообще можно добиться каких-то совершенно абсурдных оптимизаций производительности. Как то, что цикл: for (let i = 0; i < steps; i = (i + 1) | 0) {/* Фибоначчи на целых в стиле asm.js */} Будет на 20% быстрее чем дефолтный js цикл for (let i = 0; i < steps; i++) {/* Фибоначчи на целых в стиле asm.js */}
Ни те, ни другие тесты не заслуживают доверия. Слишком много факторов, вносящих замедление в вычисление. Включая даже возможный троттлинг на simd без водяного охлаждения на процессоре. Но, конечно, вызывают жалость эксперты, на серьёзных щах рассказывающие, что жаваскрипт быстрее сишарпа. Сравнение с жава и плюсами интересно. С жаваскриптом и питоном - нет. Причём, я даже могу поверить что обвязка может ускорить вызов node.js до такой степени, что он обгонит .net. Но само вычисление тут вообще ни при чём.
@@MsTim159 Как уже написал Александр, asm.js мертв. Никто всерьез на нем не пишет (разве что какой-то легаси код), но его наследие все еще живет в JS движках (я про SpiderMonkey и V8). Сейчас для решения тех же задач есть WASM и AssemblyScript компилируемый в него. Или Emscripten для C и C++. Также язык имеющий компилятор для LLVM потенциально тоже умеет компилироваться в WASM.
Все таки правильно я выбрал язык для изучения :D Правда его я тыркаю в аспекте игростроя на юнити, но даже так ощутил его возможности по оптимизации...
Будучи человеком, который чуть-чуть знаком с node/v8 internals, C#/.NET/Mono, а также с разными другими интерпретаторами, компиляторами (в т.ч. JIT/AOT), могу сказать лишь, что тесты не показательны. Что в исходной статье, что в видео. Уш прастити.
а зачем считать фиббоначи на ноде и сортировку когда в реальной жизни на ноде таким никто заниматься не будет ибо все знают что нода для построения апи, а для математики есть другие инструменты?
Фибоначи это из исходной статьи, сортировку вставил я, т.к. у меня были видео с примером натуральной сортировки и там и там, карта тоже мой пример и тоже было видео про это. То что большая часть задачь - это элементарная прослойка между БД и фронтом, так тут всё будет в базу упираться 😁
@@Kulibins1 ну так к автору исходной статьи тоже вопрос зачем забивать гвоздь микроскопом? нода хороша для постороения апи имхо это и надо сравнивать, а если нужна математика то плюсы вам в помощь или прости господи асм
@@yuriibesedin4418 сложность написания кода на c# я бы сказал что даже меньше чем на Js, а дальнейшее сопровождение уж точно проще у C#, т.к. очень много ошибок Js отлавливаем не во время компиляции, а в рантайме. Вон даже код у шарпа компактнее, он быстрее. Тут хотя бы TS нужно использовать вместо ванильного js. Тут просто если спецу по Js нужно бэк писать, то что бы не переучиваться, то node.js выход. .net c# высокоуровневый быстрая платформа, а вот во многих других мы видим либо высокоуровневы и "медленный" либо низкоуровневый и "быстрый"
@@Kulibins1 ну на вкус и цвет все фломастеры разные. Просто если заговорили про быстродействие его бы и сравнить, а удобство написания это отдельная тема хотя я наверное соглашусь что шарп довольно передовой в этом смысле ибо они не парятся по поводу обратной совместимости как в жаве и быстро развивают язык
Я могу разогнать код CompareUnsafe и сам API на .NET 7 на порядки быстрее: - 50.55% вызывается метод Concat - 10.35% вызывается метод UInt32ToDecStr - 6.69% вызывается метод Int32ToDecStr - и только какие-то 7.90% тратится на метод CompareUnsafe Вариантов как ускорить несколько. Но сразу напрашивается полное избавление от метода Concat и аллокации строк на каждой итерации. Далее, в методе CompareUnsafe не нужно считать num1 и num2. Для чего здесь вообще unsafe используется? Чтобы не тратить время на проверку выхода за границы массива? Этим можно пренебречь и остаться в safe. Еще в .NET 7 можно включить AOT или ReadyToRun. За счет этого .NET начал безоговорочно уделывать NodeJS в AWS лямбдах. Единственное место, где целесообразно сравнивать .NET и NodeJS. Теперь никакие Cold Start не помогут NodeJS.
Конечно напишите такую функцию и давайте посмотрим (без всякого сарказма). Моя функция была написана много лет назад. По поводу readytorun я тесты запускал несколько раз, поэтому не будет прям такого преимущества. И ещё я в своей функции не вижу ни каких конкатов, потом я не вижу UInt32ToDecStr и не вижу Int32ToDecStr. Мы про одну и туже функцию говорим? Как вы получили эти значения? В профилировщике производительности я их не вижу.
Чтобы переписать всю функцию API, надо знать какие изменения допустимые и какие требования к методу CompareUnsafe (ну и свободное время, чтобы написать и измерить через BenchmarkDotNet): - строки ASCII, UTF-16LE, UTF-8 или с любой кодировкой? - число всегда присутствует в строке? - число всегда в конце строки? - Может быть несколько чисел разделенных другими символами? - CompareUnsafe должен сравнивать что-то похожее на строку? - Пробелы, табуляции и так далее допустимы в конце строки? - Учитывается культура или побайтовое сравнение? Учитываются диакритики? Опишу два способа избавления от string.Concat: 1. Создать 2 буфера символов с заведомо большим размером (чтобы поместить туда строку и число) и передать 2 слайса Span в метод CompareUnsafe 2. Создать 2 двоичных буфера с заведомо большим размером (например через маршалинг) и передать Memory в CompareUnsafe Чтобы избавиться от num1 и num2, числа не обязательно умножать на 10. Допустим есть две строки: abc1000 abc00100 Сначала необходимо доказать, что строки одинаково начинаются. Потом, если идти с конца строки, то достаточно знать результат сравнения предыдущих символов и текущих символов, пока не закончится число. Т.е. сложность алгоритма O(n) при простом побайтовом сравнении. Для профилирования я использовал dotTrace с профилировщиком Tracing и включенным Real time (performance counter): i.imgur.com/096OmwJ.png Метод Concat взялся неявно из операции складывания строк: sharplab.io/#v2:EYLgtghglgdgPgAQEwEYCwAoBBmABM3AYVwG9NcL88EAWXAWQAoBKU8yjgNwgCdcJcAXlwAiCMADGIgNzsOFbn2BDRAEwCmAMxlz5CFAE5GAgNS5gzWRg4BfTDaA Реализация: referencesource.microsoft.com/#mscorlib/system/string.cs,3187 У числа же неявно вызывается метод ToString: sharplab.io/#v2:EYLgtghglgdgPgAQEwEYCwAoBBmABM3AYVwG9NcL88EAWXAWQAoBKU8yjgNwgCdcJcAXlwAiCMADGIgNzsOFbn2BDcAVlkZ5lBCgCcjAQGpcwZho4BfTBaA= Реализация: github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/shared/System/Int32.cs#L80 ReadyToRun и AOT влияют только на холодный старт и JIT оптимизации. Функция прогревается в JIT через пару вызовов, поэтому в конкретном случае разница минимальна.
@@i2um1 у вас может быть профилировщик показывать и работу самого asp.net core , поэтому вы видите еще и то что написали. В моей функции нет операций соединения строки. По существу это функция сравнения для натуральной сортировки, в ней сравниваются 2-е произвольных строки, в которых могут быть (а могут и не быть числа) указанный вами пример моя функция легко сравнит. Что-то мне кажется что не напишите вы оптимальней тому что в моём примере 🤣 Нет в моём примере складывания строк, где вы его нашли? Так же нет у числа и toString (хоть явного, хоть не явного)
Короче понятно. Что кому нравится, то и будет он(она) хвалить. Вот все вы так паритесь за производительность))) если вам хочется быстрее, то пишите на c++/c. А так рассуждения, что быстрее, на уровне переменных такое. В реальности большинство не парится о производительности, а пишут лишь бы работало. Это если уже стоит задача оптимизировать, то да. Уже начинают задумываться. А может я ошибаюсь)))
Дело не в том что хвалю что нравится, а как сказал в начале ролика: увидел статью, в которойтговорилось что нода быстрее меня это смутило, решил перепроверить - и вот результат. Далее на примере теста с сортировкой, не будет c++ быстрее, а будет тоже самое 🤣. Т.е. я могу написать на c# код который будет по производительности практически идентичным коду C. Хочу это как раз выяснить при сравнении с rust
@@Kulibins1 вы всё хорошо рассказали. Я не конкретно про вас говорю. Я в общем про комментарии. Многие здесь комментаторы пытаются доказать преимущества того или иного языка. Но ведь у одного языка есть одни плюшки, которых у другого нет и наоборот. Просто провести сравнение - интересно. А вот уже что лучше, будет спор, в котором не будет победителя. Кто-то к одному привык больше, кто-то к другому. Мне, к примеру, сложновато воспринимать работу js, с его асинхронностью, но это же не значит, что он плохой. Так же и не значит, что он хороший. Это всего лишь особенность языка. Сам я сижу на С#) Короче, комментаторы(не автор видео), не хейтите другие языки. Даже если вы думаете, что не хейтите, но на самом деле так выходит))) Надеюсь, получилось донести мысль.
@@jekaavhachev1962 я говорил что мне нравится js в виде ts. И некоторые фишки из него я хотел бы видеть в c#. Меня просто смутила статья, вот и получилось видео. А так я сам фронт делаю на Angular(ts), а не на blazor(c#). Так что все современные языки имеют своё применение и тех кто их любит.
когда сравнивают нод с си шарпом по производительности это уже уровень.. это как рнр-сты в свое время сравнивали и говорили не ну да шарп же компилируемый поэтому то быстрее но наш жмыхапэ остает совсем чуть-чуть. А вообще про многопоточность шарпа и однопоточность ноды там есть какой-то экспленейшн когда нода с одним потоком уделывает шарп видел где-то крутого нодера который норм раскидывал почему нода обыгрывает шарп но это узкий сегмент задач
это конечно хорошо в соревнованиях "кто быстрее, выше и сильнее". а что если ты начинающий и даже года опыта не имеешь в коммерческой разработке? Половина терминов, использующаяся в комментариях и в видео кажутся чем-то неизвестным. полюбому напишу какое-нибудь унылое говно, которому никакие тесты не помогут. как быть? как развиваться, чтобы впоследствии не выглядеть тупым идиотом на фоне дискутирующих?)
У меня канал в принципе для более продвинутых разработчиков. Хоть есть и для начинающих материалы. Для начинающих очень хорошие материалы по фронту у Владилена Минина. У меня есть 2 видео про каналы которые рекомендую и там может быть что пригодится. Для бэка C# прочтите для начала книжку Рихтера (что бы понимать c# и . net), после этого можно уже мои видосики как по rest посмотреть, я почти всё что нужно рассказал.
@@Kulibins1 За книгу крайне благодарствую) На работе как раз бэк с использованием или на (понять не могу как правильно) .NET сделан. Руки все тянутся к Ангуляру. Так что кто знает, может быть недофуллстеком пополнится наш мир в будущем) Спасибо за те видео, где советовали каналы других ютуберов
@@Kulibins1 никого не хочу оскорбить, только хотел сказать, что Дж Рихтер "CLR via c#", не для новичков совсем, может оттолкнуть вообще от изучения этого направления.
@@Kulibins1 number в JS это не обязательно double, а на усмотрениие движка. Код не идентичный получился, функция в JS на каждый запрос заново аллоцирует "rect" и "pr", проверяет req.url в каждом условии..Сортировка в JS написана максимально медленно, с созданием объекта в цикле, в то время как в C# заявлена "самая быстрая функция".
@@yoloopen если вычисления идут с double и там и там, то и тут и там будет double что бы не думал движок v8 🤣 Вынести rect и pr, ничего не поменялось. И в c# rest и pr это переменные функции main скрытой под капотом. Можете предложить свою функцию натурального сравнения (обратите внимание на слово натуральное)
@@yoloopen только что замерил если вынести все эти переменные до вызова createServer, то увеличится на 1,5 запроса в секунду, было 96.3 запроса в секунду, а стало 97.8, т.е. если честно существенно разница не изменилась, а так спасибо за совет. Для JS eсть стандартная функция натурального сравнения через localeCompare, но оно ещё хуже работает, причём заметно
Unsafe в c# - это плохая практика. Уж лучше тогда взять Rust - Actix Web. Там сразу двоичный код исполняется. Node.js в принципе не может быть быстрее с одним потоком и динамической типизацией. Расчет типов и исполнение в одном потоке как раз жирный минус ноды.
И чем же она плохая? Просто когда не умеют писать, то можно накосячить 🤣 а так это очень даже применимо. Далее есть еще simd команды они тоже есть в . net, но это еще более низкоуровнево, но ведь тоже кто-нибудь скажет зачем. Мне java разработчики говорили зачем переопределение операторов (есть в c#, нет в java), да и зачем структуры и многое другое.
@@Kulibins1 имею ввиду, что unsafe в C# нужно уметь готовить и правильно совмещать с безопасным кодом. Это мало кто может. По - этому, надёжнее разрабам написать сверхскоростной сервис на Rust и дёргать его. Это если нужны наносекунды и минимум памяти.
@@СерёгаСокольский да конечно нужно уметь. И главное нужно оптимизировать, то что тормозит, а то сколько угодно можно ускорять, то что в общий вклад вносит 1%, а то что тормозит нет.
Node.JS доступна полноценная многопоточность с shared memory. По поводу динамической типизации - она влияет только на производительность первых вызовов функции - потом функция пропускается через JIT. Но и на первых вызовах, если используются более-менее статичных структуры данных, то под капотом они представляются классами C++, и работают с соответствующей скоростью. Так что да, "на старте" Node однозначно будет уступать С#, но если дать JIT разогреться - результаты, вероятно, выровняются
@@alekseybobyr1473 .net это изначально jit. И нет не выровняются, а то не придумывали всякие wasm. Но скажу еще раз нынешний JS просто фантастически быстр и для многих задач будет достаточен. Только если писать, то уже на TS, т.к. без типизации, столько ошибок будет в проекте, даже опытные разработчики смотришь косячат на элементарном коде. Но для меня бэк это .net c#, а фронт это angular.
ну вы тоже не объективны ваш последний тест фуфло, понятно что нода позволяет запускать меньше потоков одновременно но почему вы не снизили в последнем тесте количество до 400х?
@Cosinus 0 мне кажется php уже все, доживает последние дни в Легаси проектах. Какой смысл в серверном рендеринге сейчас? Современные подходы рулят: микросервисы и фронт spa.
@Cosinus 0 Для энтерпрайза по сути только 2 варианта есть: .net или Java. Это конторы у которых есть все свое, среда разработки, базы данных и т.п. Больше никто не может предоставить поддержку сразу по всем направлениям. Серьезные игроки не будут экономить на спичках и брать какой-нибудь PostgreSql или MySql, возьмут готовое и нативное, все и сразу.
Мультипарадигменность сильно бустит js (ts) в моих глазах по сравнению с С#. Плюс, когда все чем ты занимаешься на беке это ходишь в базу, вся производительность упирается во второй тест, а она в нем ровная. Какой смысл писать на менее удобном языке (литералы js - произведение искусства), который позволяет быстро с числами поиграться, если ты не собираешься с ними играться? Всю тяжелую работу можно выносить в микросервисы или сишные вставки на крайний случай (которые неплохо бы применить в самой производительной версии кода, рас уж ансейв испозьмуем. Вставки для таких случаев и нужны). Вообщем какое-то пустое сравнение, никаких интересных выводов из него не следует.
С моей точки зрения самое удобное это c#, у него гораздо больше всяких приятных фишек. В TS есть приятные моменты которых нет в c# и я их тоже хотел иметь, но в в c# гораздо больше всего, чего нет в других языках. По поводу того что только ходит в базы, посмотрите моё видео на главной странице, где я рассказываю про свою SCADA систему, посмотрел бы я как бэк SCADA написать на Js, если это и возможно будет сделать то усилия по сравнению с c# будут во много раз больше. Не все задачи представляют из себя простенькую прослойку между базой и фронтом
как понял народ пишет. В прошлый раз в видео сказал что Blazor которые через wasm работает дико медленно, до сих пор у меня спрашивают а оптимизированную версию ли я сравнивал. А тут виртуальная машина .net работает по верх виртуальной машины wasm, и это медленнее чем обычный JS, причём значительно.
@@Kulibins1 А они просто собирают .Net под Wasm? По идее они могли бы некоторые гарантии рантайма переложить на сборщик мусора js, а также завязать некоторые другие рантайм фишки на JS или Wasm рантайм. Чтобы банально было ментше сборщиков мусора и так далее
@@vas_._sfer6157 не всё так просто, по другому не получится .net запустить в браузере. Но главное оно так медленно, что не имеет смысла на больших проектах. Не так критично, но и обратное js хуже на бэке.
Ничего не понял? Зачем mono? .net уже несколько лет на всех линуксах работает. Вроде в видео про это говорил? У нас в проекте всё в кубер собирается с линуксовыми серверами. mono давно не актуален.
Там нет тестирования в браузере!!! посмотрели бы внимательно. В браузере я лишь показал странность того что метод rest открывается по разному. А дальше идёт тестирование в JMeter. Вы не правы.
Для чего использовать var вместо double? В рекомендациях Microsoft четко написано, что var используется исключительно для анонимных типов данных. Использования var очень плохая практика. Разработчики должны внимательно смотреть на то что в правой части записи. Кроме того, в режиме отладки и релиза компилятор может использовать разные типы данных. Так зачем таким заниматься? Visual Studio спокойно предложит дополнить все базовые типы. Лично я не пропускаю PullRequest, где используют var вместо базовых типов данных.
из правой части чётко видно какой тип данных, и код выравнен а не разбегается из-за старого си-шного синтаксиса. У вас свои требования у меня свои 😉, тут главное единообразие, что бы все делали по одному принципу в одной команде.
вкусовщина. У майкрософт рекомендации каждый год на обратные меняются. они в последней версии решили в венгерской нотации вернутся и рекомендуют префикс s_ для статик филдов писать. вар удобен, тем что всегда единообразен, плюс позволяет потом безопасно менять типы функций без изменения вызывающего кода. ИМХО очевидное знание типа не должно быть необходимо при чтении кода. var salesOrder = base.GetDocument() зачем мне знать что возвращаемый тип SalesOrder (если это генерик класс к примеру) если семантика прямо это утверждает? Особенно я обожаю такое: SalesOrder salesOrder = new SalesOrder(); нужно больше дублицирования! Эксплисит тайп нужен только тогда когда необходимо явное знание о типе, но очень часто это признак плохого кода: SalesOrder document = base.GetDocument();
Проходил стажировку в одной очень крупной компании, которая, если продолжит в таком же темпе развиваться скоро достигнет (лет через 5) компанию Microsoft. var - везде MUST HAVE !!! var - forever!
По сравнению с чем? Всегда был быстрее java, да и всего того что со сборщиками мусора. Медленным он никогда не был. А вот сборщик мусора, особенно если код плохой, уменьшает производительность, но бороться с утечками памяти гораздо легче + в .net много завязано на структуры, кода у нас что-то хранится в стеке и освобождается оно практически бесплатно. Я себе поставил в план сравнить с Rust
И да плохой код из любой платформы сделает г... о. Поэтому в первую очередь нужно писать хороший код, а потом уже будет значить платформа. Сколько раз видел всякие повторные не нужные вызовы функций или когда вместо использования специализированных структур dictionary (c#), map (Js) использовали просто массив и делали поиск по нему.
А почему код однопоточной ноды написан полностью в блокирующие стиле? Функции хендлера синхронные, блокирующие, fs readfile синхронный.
Типа потому что на net код тоже синхронный? Чтоб честно было? Тогда чтобы было честно , может тестировать на системе с одним ядром (в контейнере).
Вызов в один поток тоже на . net быстрее на задачах где хоть что-то делается
Вы асинхронную Ноду заставили против ее природы работать синхронно, а потом говорите, что .net быстрее. А если раскидать Ноду по потокам, которые у нее есть и дать работать асинхронно, каким окажется результат сравнения?
@@albalyu где я заставил её работать синхронно? Можно меня ткнуть в это место 🤣
@@Kulibins1 Читать файл синхронно, потом запустить сервер, в запросах к которому тоже читать файл синхронно - это как бы синхронно. Плюс тяжелая математическая операция, которую в реальном проекте вынесут в отдельный поток, дабы не блокировала текущий. Плюс некоторое количество вещей в коде, которые в реальных проектах так не пишут. Плюс Ваши утверждения о типах чисел в Ноде, основанные явно не на документации к V8, плюс утверждения о многопоточности, которые не соответствуют действительности. Это не сравнение производительности в реальных условиях. Это сравнение теплого с мягким. Они разные и работают по разному. Корректные тесты должны максимально учитывать преимущества тестируемых систем, чего в данном случае нет.
@@albalyu файлы и там и там читаются синхронно, и этот небольшой файл уже в кэеше, и при тесте выдаёт максимальное число которое вообще возможно и там и там (упёрлось в канал). Ваши предложения странноватые, вы предлагаете аналог webworker использовать? Так на внутреннюю пересылку потратится больше времени. И тогда я включу потоки для c#, как думаете какой будет результат?
Круто сделать подобное сравнение ещё для. Net java c++
на node js у вас initial connect занимает 300ms(видимо косяки в настройке сервера). само же вычисление - waiting for server respond занимает 20ms на node js и около 30ms у C#
На других запросах всё быстрее, те же хелоу ворды, и чтения файлов.
Спасибо, отличное видео, посмотрел с удовольствием, хотелось бы посмотреть сравнение с GO!
Придется похоже и сравнение с go в план ставить
@@Kulibins1🤣🤣
Отличное тестирование, я бы еще посмотрел такое же сравнение с golang =)
Если есть опыт с go, то можно переписать тесты. Я просто сам пока go не собираюсь изучать. Сам только с rust еще сравню.
Очень интересные видео у вас, спасибо
Рад что нравится
какие мысли по поводу trpc vs REST?
Пока ни каких. На проектах для связи бэка и фронта больше GraphQL использую, а сложный бэк больше через шину с друг другом общается.
5 лет пишу js/ts, вдохновил на изучение .net )
Вот вы говорите "Смотрите следующие видео будет интересно", и я верю, что будет интересно =)
Вера в интересное - это хорошо 👍
а бэк может по разному настроен из коробки? нужно инфа в количество потоков, процессов, память хз.. предлагаю в эту сторону еще посмотреть слишком большая разница чет в производительности.. либьюви количество памяти-потоков.
Да все из коробки. Характеристики компа зеон 12 ядер, 24 потока, памяти 64 Gb. Если смотреть загрузку памяти, то она копеечная там что-то 500 Mb. Самое интересное процессор тоже не загружен, при тесте больше всего сам jmeter взял, но всё равно общая нагрузка всего не превышала 25% проца, т.е. как бы сказать что мол node в одино ядро работала, а .net нагрузил все ядра, то тоже нет. У меня есть видео про моё рабочее место там характеристики компа видно подробно.
1) Node js вроде уже 100 лет в обед как поддерживает многопоточность, разве нет?
2) Для тяжелых вычислений есть возможность писать на Ноду модули на Расте или C++.
Когда-то давно был у меня проект на VB (Легаси), а сложные вычисления я писал на ASM с использованием mmx и sse. Вы предлагаете нечто похожее. Для этого либо вы должны C++ знать, либо должен другой разработчик эту работу сделать. Если вы специалист по C++, то сомневаюсь что будете писать на Js, C++ сник может зарабатывать больше чем Js ник, хотя бы из-за того что их меньше. Разработчиков Rust видел еще меньше, но тесты напишу что бы rust сравнить с c#.
@@Kulibins1 тема модулей на плюсах довольно обширно раскрыта в мануале к ноде, так что это вполне себе официальная костылизация=)
@@nitroexpress9928 ну к c# тоже можно подключить DLL на c++ причем есть mc++ это смесь менеджмент и анменеджмент кода на c++. И даже win api вызывать и кучу других малоприменимых сценариев, например можно openCl (я пробовал)
Если я правильно помню у ноды кластера используются, хз насколько они лучше или хуже чем многопоточность, но я думаю надо было и кластера чекнуть. Плюс мне лично хотелось бы понять насколько сильно нода отстаёт от Шарпа в обычном rest api, так как если париться насчёт ручного управления памятью то можно и весь бэк на golang/rust написать, или на питоне и всё вычисления на сишных dll-ках делать
У автора статьи была просто нода, а так да можно и с клатером сравнить. Но я смотрел и в один поток когда из браузера запрашивал - результат был виден, всё равно .net быстрее, иногда значительнее
сайты на шарпе тоже кластером масштабируют)
В ноде нужно явно делать форки для кластеров, при этом они не сильно помогают в производительности, так как нода по факту работает многопоточно за счет микротасков и ивентлупа.
@@Kulibins1 скачал код из Вашего репозитория, у меня этот /map что на ноде, что на дотнете отрабатывает за 20 +/-2 ms (i5-9600K, Linux Manjaro, .NET 7, NodeJS 18). Откуда такая огромная разница на видео - непонятно. Вы на винде тестили?
@@nitroexpress9928 тестил на Винде. Но не нужно говорить что тут винда виновата и что Линукс в разы быстрее, это не так. Проц у меня зеон. Сколько у вас показал jmeter? Конфигурационный файл вместе с исходниками
То, что Node.js нет многопоточности - это давно неправда (смотреть в сторону модуля worker_threads). К тому же никто на Ноде не пишет реальные запросы в синхронном блокирующем стиле. Это просто неэффективно. Даже в самом начале мануалов для начинающих говорится, что надо использовать асинхронный неблокирующий код. Плюс движок V8, а Нода - это именно V8, для разных типов чисел использует разное внутреннее представление, и если мы переменной присвоили целое, то и обрабатываться она внутри будет как int, а не как double. И только если мы присвоим вещественное число, то переменная поменяет свой тип на тип с плавающей точкой. Прежде, чем что-то утверждать о том, с чем Вы не очень знакомы, хорошо бы посмотреть доки - а вдруг все совсем не так, как Вы себе представляете. Также сила Ноды в том, как она множество запросов, которые обрабатываются асинхронно, а не один за другим. И время их выполнения частично перекрывается. Да и сама Нода со старта работает сразу в несколько потоков и для разных надобностей используются разные потоки. Ничего не имею против C#, но отказаться от всех преимуществ Node.js, а потом утверждать что C# быстрее - это не очень красиво.
Какой код из тестов вы предлагаете "улучшить" только пожалуйста конкретно. Я готов принять ваши предложения и перетестировать
Реальное предложение: Вы находите программиста на Ноде с большим опытом (не меня - мне лениво), договариваетесь с ним о функциональности, работу которой хотите протестить и он пишет максимально эффективный код на Ноде, опираясь на годы своего опыта, а Вы на C#, опираясь на годы своего опыта. А потом можно сравнивать. Это и будут одинаковые условия, с моей точки зрения.
@@albalyu я написал полностью идентичный код. Он не максимально эффективен на c# ( максимально эффективен был исходный мой код). Я же просил дать реальные замечания к коду на Js, то пишете что я как-то заблокировал асинхронность/многопоточность Js, то огромный ответ что внутри движка v8 Js number может соптимизироваться до int (хотя все вычисления с double в карте идут и ни какой оптимизатор ничего не делает). В общем не надо голословных утверждений.
@@Kulibins1 Вы не могли написать полностью идентичный код для систем с таким разным подходом к разработке. Уже то, что Нода асинхронная, а Шарп синхронный говорит о том, что работают они по разному, и писать для них надо по разному, а не идентично.. Ваши вопросы ко мне говорят о том, что Вы даже не понимаете проблем Вашего JS кода. Теперь конкретно: Вы сказали в видео, что все числа в JS представляются в виде double, однако это не так, V8 имеет различные внутренние представления для различных типов чисел. Вы сказали, что в Ноде нет многопоточночти - это уже давно не так. Вы написали синхронный блокирующий код для асинхронного сервера и утверждаете, что так и надо. На Ноде так даже джуны не пишут, потому что по рукам получают ). Вы используете сохранение элементов массива каждый раз увеличивая его размер и утверждаете, что это нормально, но такое сохранение данных в массив работает в 20!!! раз медленнее, чем если бы Вы сразу создали массив нужной длины. Для массива размером 10 000 000 элементов время выполнения цикла заполнения элементов значениями будет соответственно 12-15 мс и 250-300 мс на моем компьютере. Разница почти в 20 раз. А Вы говорите, что это не имеет значения. А еще про корректные тесты... На сим разрешите откланяться. А ревьюить Ваш код и предлагать Вам тесты, увольте. Вы и сами можете придумать еще много такого же 'корректного', как и эти.
И да, как Node.js разработчик с такими утверждениями Вы бы не смогли пройти собеседование у меня даже на уровне джуна.
Пример про фибоначчи в node просто не работает (когда число становится большим js просто возвращает infinity). 3:30 полное заблуждение, так как js однопоточный при выполнении цикла он просто заморозится и не будет ничего дальше выполнять пока цикл не закончится ( shyngy/simple-loop ) - github тут пример рекомендую запустить и посмотреть, еще прочитать про event loop
Про то что число становится бесконечность я знаю, результат же запроса выводиься , в отличии от первоначальной статьи. По поду того что я не прав на 3:30 тут пока я не вывел результат, то функция выполнялась максимально быстро, как только вывел, то всё стало на свои места. Как устроен event loop, я как бы знаю (может не всё, т.к. там оптимизаций вагон и маленькая тележка 🤣 )
@@Kulibins1 про 3:30 и вправду node быстрее, так как он просто не считал до конца, а завершил цикл досрочно. 1. Цикл начался, число фибаначчи постепенно начало увеличиваться 2. в один момент число стало настолько большим что буффер заполнился. 3 цикл прекратился вывелся результат Infinity. “я не эксперт в node но по моим наблюдением все работает примерно так”
@@shyngyskhanbokikhan6782 не смотря на такую оптимизацию всё равно оказался медленнее. И это прогнозируемо. И как тут мне многие пишут что мол ноду не берут на вычислительные задачи, а на задачах где всё в БД упирается и разницы не будет. Я это всё понимаю и говорил что ничего в Js плохого не вижу. Тут обман исходной статьи меня немного вывел из себя 🤣
@@Kulibins1 про event loop в github выше есть два примера, которые показывают когда js игнорирует цикл и продолжает дальше работать, и когда он ждет полного выполнение цикла а потом выводит результат.
@@shyngyskhanbokikhan6782 спасибо. Обязательно посмотрю 👍
Вопрос не по теме, но хочется задать. C#/NET не владею, но слежу из далека. Скажите, с учётом рывка в развитии этих технологий + crossplatform'енность Core, можно ли сказать, что эта связка вполне себе может конкурировать с PHP/Python/Ruby для быстрого создания прототипов в web, да и вообще web-проектов? И хостинг уже не является фактором сложности/дороговизны, т.к. вполне себе можно развернуться на linux?
Можно развернуть на линуксе. И смотря в чем вопрос. Если вы хотите делать фронт, то я не люблю server side rendering и все перечисленное именно его и делает. В .net есть и серверный и клиентский рендеринг, но клиентский рендеринг в .net "тормоз". Я делаю бэк на .net, а фронт на angular. Из опыта обычно потом говорят берите и дорабатывайте прототип до коммерческого использования, поэтому и прототип хорошо бы делать правильно. Вот лично для меня сделать прототип на .net + angular займёт столько же времени как кто-то на PHP/Python/Ruby сделает тоже самое. А может и меньше если еще к этой связке добавить .net + GraphQL + Angular
@@Kulibins1 добавлю, что разработка с нуля - это не то же, что с использованием фреймворков, коих у PHP не мало.
@@GreenDimka1 У всех платформ фрейворков не мало.
@@Kulibins1 Понял, спасибо. Просто хотел подтвердить гипотезу, что для нового и при этом даже небольшого проекта можно смело брать .net вместо, например, php + laravel или python + django. Вопреки давним мнениям о том, что .net - это дольше и дороже.
@@Дэн-з7н если вы так сравниваете, то конечно можно.
17:16 (с# сервер может отвечать на большое количество запросов): А что если нод джээсовский сервер горизонтально масштабирован, то есть у нас за раз работает несколько инстансов этого веб-приложения. Все равно с# сервер будет отвечать на большое количество запросов чем нодовский?
Уже несколько человек об этом написало, но ведь и сервер .net тоже можно масштабировать горизонтально. Тут именно дело в том что автор исходной статьи утверждал что node.js быстрее .net c#, я показал что это не так.
@@Kulibins1 вот только в рамках одного компьютера кластерный режим ничего не даст Шарпу, а Нода в задачах типа этих бенчмарков становится быстрее в разы.
@@nitroexpress9928 может быть. Но вон запустили в кластером режиме ноду получили, только то что она в картах сравнялась (но я бы перепроверил 🤣) в тесте натуральной сортировке отставание в разы даже с кластером.
А что если включить Воркеры в ноде и распределить нагрузку по ядрам?
Тоже вариант, но даже в один вызов если смотреть, то nodejs медленнее. Для языка js, оно работает фантастически быстро, но против мироздания не пойдёшь в C# структуры (их кстати в большой java нет, а как бы всё делать объектами, то сборщик мусора перегружен), прямой доступ к памяти (пример из натуральной сортировки), всякие span и т.д. Если писать простой код, то node.js может и достаточно. Могу кстати и с финансово технической точки зрения обосновать что многопоток лучше чем кластер (хотя и на .net делаем кластера, но тут их будет избыточно - на проекте не дали кластер к postgre сделать, типа обычная репликация без распределения нагрузки 🤔)
@@Kulibins1 я не шарю в .net core, поэтому закрался такой вопрос, а случайно тот вебсервер, который в C# создается в коде, случайно не использует под капотом какой-нибудь пулл воркеров для обработчиков запросов? Чет уж сильно много разрыв в 30 раз, не могу поверить, что там такой оверхед в ноде
@@PavelAShvedov в 30 раз версии где я использую оптимизации прямого доступа к памяти. Этот код равен тому который был бы на голом Си. Представь что каждое обращение к элементу массива, проверяет а не вышел ли ты за его границы, а в коде с прямым доступом я не делаю таких проверок. И на самом деле это еще не максимум который можно выжать, тут можно было бы использовать simd команды, но сложность кода реско возрастёт и придется писать несколько спец версий, например под arm и x64 (sse ... avx), а я последний раз писал только под первый sse. Сколько даст прироста simd, не знаю, мне пока хватает и моего варианта что быстрее аналогов.
@@Kulibins1 ну если дотнет никак не параллелит обработку запросов, и все дело в такой лютой оптимизации под конкретный кейс, то спорить не буду, но с другой стороны показательность этого бенчмарка тоже крайне субъективная, если хочется в ноде заморочиться, то можно написать решение на том же С++ и подцепить к ноде и вызвать, проблема и подхода с упоротой оптимизацией с С#, и с извращениями с С++ для ноды только в том, что в реальной жизни, в каком-нибудь энтерпрайзе, никто не будет так корпеть над тормозящей функцией, проще поднять еще один инстанс приложения и сбалансировать нагрузку, в 99% проектов имеено так и сделают. Максимум что будут пытаться оптимизировать руками, это запросы к БД, если ОРМ-ка не справляется, так как чаще всего основные тормоза в типовых веб-приложениях именно там, а чем дергать эту бызу данных уже не суть важно, C# там, нода или elixir. Сугубо ИМХО
@@PavelAShvedov задачи есть разные не только прослойка между базой и фронтом. Посмотрите ролик про мою SCADA систему, на главной страничке.
это же все не важно, разве нет? кто на чем пишет, тот на том пишет :)
очевидно что dotnet быстрее, но это не важно
очевидно что в nodejs войти проще, но это тоже не важно
современные задачи (большинство из них) требуют скорости их решния (именно скорости написания кода), но не скорости выполнения этого кода
гораздо важнее вопрос поддержки кода, вот тут стоит призадуматься :)
что будет через год? сможешь ли ты взять проект написанный год назад и скомпилировать его сегодня? сколько усилий тебе понадобится?
а продолжить разработку и развить проект?
я бы наверное из этих соображений исходил
Да я тоже несколько раз сказал что главное качество кода и испоганить можно любую платформу, то что сделано на "лучшей" платформе не гарантирует лучший результат. Но повторяюсь: увидел статью где говорилось что нода быстрее, причем с тестами. До этого видел видео (пару лет назад) где "нодер" просто рассуждал что нода быстрее всего. Первое что приходит в голову (на ноде я не делаю свои проекты) может действительно нода лучше? Сделал тесты - нет не лучше. А так я не настаиваю и давно вышел из возраста холиварщиков, кому что нравится тот на том и пишет.
Нод js поддерживает многопоточность. cluster, worker_threads, child_process
Это не многопоточность. Я про это сейчас делаю видео. А если в крации это горизонтальное масштабирование сервиса. Есть большая разница, а то мне недавно на собеседовании убеждал соискатель убеждал что в js в браузере если сделать setTimeout это тоже будет параллельная работа. Нужно понимать что это и как оно работает, какие преимущества и недостатки
@@Kulibins1
Из официальной документации ноды:
"The node:worker_threads module enables the use of threads that execute JavaScript in parallel".
Также, неблокирующий I/O работает засчет libuv, которая, в свою очередь, использует отдельный поток.
setTimeout - и правда ничего общего с параллелизмом не имеет. Это асинхронное программирование. Я про это и не говорил
@@grenadier1653 про setTimeout я написал как пример абсурдного заблуждения. Тут тоже самое, потоки в node это на самом деле не потоки, а отдельные процессы. Это не есть плохо, у каждого подхода есть свои недостатки и преимущества. Скоро будет видео на эту тему
Number - это не double из C#. Представление чисел в движке V8 - это весьма комплексная вещь (SMI & Double), которая во многом скрывает реализации под капотом, а сверху еще и JIT добавляет оптимизаций.
Учитывая, что явных присваиваний дробных чисел нет, переменная меняется в цикле, то я уверен, что там точно такой же int, как и в C# на выходе будет (вы можете прекрасно раскрутить всё и посмотреть, в какие представления оно раскручивается, как в том же sharplab)
Не нужно придумывать 😉: Обычные числа в JavaScript хранятся в 64-битном формате IEEE-754, который также называют «числа с плавающей точкой двойной точности» - это из документации
@@Kulibins1 гуглите в сторону SMI (Small Intergers) в движке V8, будете ОЧЕНЬ сильно удивлены. а по поводу реализации стандарта IEEE-754 - SMI никак ему не противоречит от слова совсем
@@ilyachursin7369 ну тогда node еще медлее, если она проиграла честному double. Кроме того в моём примере с картой, там все вычисления с double и их ни как не оптимизируешь. И т.к. их не мало разница в 5 раз. В общем в моём утверждении что number = double есть возражения?
@@Kulibins1 конечно есть, number - это НЕ double, как минимум из-за того, как оно реализовано внутри
А то, что node.js проигрывает - оно и понятно. Числадробилки - это явно не тот бенчмарк, в котором nodejs сильна :) да и приминительно ко всем тестам, явно оно будет проигрывать шарпам. Тут как бы классические холивары на тему - А ЧТО ЖЕ БЫСТРЕЕ (ирония на тему - пишите на asm, там уж точно быстрее всего)
Было бы не плохо переделать последний тест на С# без unsafe и посмотреть разницу.
В видео про натуральную сортировку у меня были варианты. Тут именно была цель показать что с оптимизацией будет огромная разница. Теперь вот хочу с Rust сравнить 🤣
Сейчас уже не будет никакой разницы (я проверял). В C# довольно хорошая оптимизация. Есть неочевидные способы оптимизации кода, но они не связаны с unsafe.
А можно не страдать хернёй
А нафига синхронно читать файл на ноде? В статье конечно тоже синхронно читают, но это же принципиальный момент. Или может я чего не улавливаю?
А оно уже не влияяет, читаем один файл который закешировлся. Я пробовал итасинхронно, для теста нет разницы
На ноде надо читать файл стримом и сразу пайпить в рес
Суперское видео, где видел по той же логике сравнивали ПХП с шарпом и кричали смотрите какая пыха быстрая))
Хоть на PHP можно и делать web api, но в основном делают серверсайд рендеринг приложения, а этотс моей точке зрения уже не имеет смысла. Кроме того интерес к PHP снизился очень сильно и вероятно останется только на Легаси проектах. В общем сомневаюсь что кто-то из новичков сейчас начнёт его изучать. Поэтому даже если увижу что кто-то скажет что PHP быстрее, то я посмеюсь и не буду "опровергать". Тут от сравнения с js словил замечаний, то тесты (которые из статьи) не те, то мол нода многопоточная (это не так, народ путает отдельные процессы worker thread с потоками - запишу про это видео) то кластер не запустил, то еще что-нибудь. ПРОТИВ НОДЫ НЕ ИМЕЮ НИЧЕГО ПРОТИВ, вполне рабочая вещь.
@@Kulibins1 Спасибо за развернутый ответ. По комментариям нужно бить только конструктивными примерами. Ждем новых видео.
Глянул репозиторий для С#. Не увидел включенным ServerGC ни в проекте ни через рантайм конфиг. Может стоит через environment variable, но если тесты были с GC in Workstation Mode, что скорее всего и было, иначе на 100 процентов бы загрузил проц, то стоит врубить серверный и перепроверить))
Да запускал в десктопном режиме. На работе автоматом собирается докер образ уже под серверное применение и я это упустил при запуске. Обязательно перепроверю
Классный материал 👍А где же эльфы? (эту шутку знают, толко те кто в теме)
Эльфов нет 🤣
Правильно ли я понял что С# не использовал многопоточность и загрузка была только одного ядра в обоих случаях?
Как минимум была запущена с десктопным приоритетом
@@Kulibins1 я не о приоритетах. Насколько я понял ваш тестовый клиент имитировал паралельных клиентов. В этом режиме очень важно распараллелить сервер. В nodejs это нужно делать в явном виде, чего небыло сделано. Если C# распараллеливает по умолчанию то ваше доказательство неверно.
@@user-0xDEEDBEEF там и одиночные запросы на .net быстрее если они хоть что-то реально делают. Уже комрад нодер запустил ноду в кластере и сравнил. У него похоже упёрлось в пропускную способность на Фибоначчи, а вот тест с сортировкой всё равно в разы быстрее на c#. Как бы Обалденно не оптимизировали Js (а они реально сделали практически чудо) c# быстрее. Кстати я тут подумал и тесту карты на Js я подыграл, т.к. по хорошему раз я с точками в c# работаю со структурами, то в Js я должен был использовать объекты, но я переписал математику что бы не было этих объектов, работа была только с массивом number
@@Kulibins1 ну понятно что и при распараллеливании js упрётся. Вопрос был только в эквивалентности вашего сравнения.
@@user-0xDEEDBEEF каждый под в кластере стоит денег. Например у нас на каждый cicd-шники еще 0.3 ядра вешают типа на обслуживание + балансировщик для кластерера из ноды. А эти вопросы я даже не сравнивал 🤣, С учетом что и в однопотоке c# быстрее.
брать ноду для Cpu bound операций.. эт странно кшн, нода ж в io хороша вполне. Да и кушает сильно меньше
Первые 3-и теста из статьи.
Node.JS он не про скорость и не про оптимизацию, он про business needs. Когда хочется иметь команду, в которой бэкендеры и фронтендеры хотя бы частично взаимозаменяемы и какие-то наработки использовать и на фронте и на бэке. Тогда и мобильные приложения можно делать на React Native - вообще красота!
Да я ж что против? Еще раз увидел статью где сказано что нода быстрее, решил перепроверить. Вот результат. А так да если есть хороший разработчик js, то ему бэк легче написать на ноде чем учить что-то другое. И как я сказал скорость js по сравнению что было раньше очень хороша и для многих задач её за глаща. Но вот лично у меня есть задачи где нода ни как не справится, это кстати не обязательно вычислительные задачи, например общение с оборудованием по низкоуровневым протоколам. Ну и вычислительные задачи, особенно со специальной оптимизацией на c# быстрее. Кстати кто знает на доде есть реализации DI (для фронта есть в Angular, а для бэка?)
@@Kulibins1 nest.js
в таком говностартапе я бы никогда в жизни не стал работать, если аргументом выбора ноды является "один язык на фронте и бэке". многие фронтендеры даже жс экспертно не знают из-за формошлепства, а их еще на бэкенд пускают
И чем вас блейзер не устраивает? Один язык для фронтенда и бэкенда, плюс скорость.
@@uvwzyx тебя и не позовут) хаха
Есть подозрение что исходная статья просто развод, примерно как в анекдоте про негров и баскетбольный мяч, сколько уже таких было, и сколько еще будет ...
И хотя результат очевиден заранее, но разбор полезен и интересен. Еще интереснее было бы добавить Java, возможно еще что-то новомодное, типа Go или Dart.
Ноду корректнее сравнивать в PHP и Python, хотя последний вероятно будет в аутсайдерах.
Дальше буду делать и с другими языками, раз тема зашла.
@@Kulibins1 Думаю у Rust есть шансы уделать C#. Все-таки unmanaged code и мощная семантика.
@@vas_._sfer6157 может и есть, только тут уже скорость разработки упадёт и стоимость сопровождения увеличится. И нужно тестировать, что бы сказать на сколько разница. Может кто сможет мои тесты переписать, для сравнения?
@@Kulibins1 Ну не знаю. Непонятно с чего она вдруг скорость разработки должна уменьшиться. Да и фреймворков уже полно, нет проблемы ни с чем.
Единственное проблема - это относительно долгая скорость компиляции для больших проектов - но это фиксится разбиением проектов сначала просто на крейты, а потом и на микросервисы, если они нужны.
@@vas_._sfer6157 если разбираетесь, то можно мои тесты переписать и сравнить какая будет разница.
так, хорошо, а на golang? )
то же интересует
Не работал с Go, могу конечно сделать по аналогии.
@@Kulibins1 ждем с нетерпением
Отличное сравнение 👍
+ За нодой что на фронте и бекенде используют один язык.
Хотелось бы увидить сравнение выдачи через REST API, так в практике это то что используют.
Лично сам я предпочитаю C#.
ну тут как раз был REST, правда только геты.
В .NET также можно использовать C#, что на стороне бэка, что на стороне фронта. Правда, без редких обёрток над JS, не обойтись…
@@ЭдуардКузнецов-ы7у да blazor. Но посмотрите видео, ссылка в описании, где я сравнил производительность Blazor, она ОЧЕНЬ плохая.
@@Kulibins1 , если я правильно помню, у Майкрософт в документации у Blazor стоит статус «Non-production»…
@@ЭдуардКузнецов-ы7у У Blazor как бы 2 режима серверный рендеринг и клиентский. Смысл в серверном рендеринге не вижу, даже из Angular его выпилили. А клиентский, через wasm даже с бэка запрос (увесистую json-ку) получает в разы медленее чем обычный js. Я после этого не стал глубоко изучать документацию по Blazor, т.к. смысл изучать, то чем не буду пользоваться, хоть и .net + c# дольше всего занимался.
3:23 "Оптимизатор js берет и выкидывает всё что написано до..."
Приведите пруфы, звучит очень смело))
Тут смотрел по тестам, если ничего не менялось во вне, и результат не возвращался, то скорость такая, как будто-то выкинул. Как только возвращаешь, то скорость резко снижается
Спасибо за интересное сравнение.
Интересно было бы еще сравнить их в облаке в условиях когда они создают одинаковую нагрузку на сервера, так будет совсем честно и приближено к реальности.
Понятно что шарп быстрее, но будет ли он настолько же быстрее в таком случае )
А чем облако отличается от того что мы тестируем? Только тем что канал связи может оказаться узким местом?
@@Kulibins1
о том и речь. Если канал связи будет например через WCF (которую в Core подымают из могилы), то потери на транспорте будут огромные.
@@vasiliigodunov1746 зачем wcf? Есть grpc, есть шина. Я уже отказался от wcf давно. Да и то когда для wcf сделал свой сериализотор, то и wcf был быстрым
@@Kulibins1
я тоже думал, что WCF был быстрым, но тесты показывали обратное. В нём были большие потери на этапе применения всех его замечательных декларативных политик. К каналам претензий нет.
@@Kulibins1
ну а если взять тот же grpc и примотать к нему аутентификацию по SSL сертификату, то замечательная технология Google превращается в шлак от MS :)
MS гениально умеет добавлять проблемные зоны в транспортные протоколы
Приятно, когда любимая технология побеждает :) Вообще, давно уже известно, что любые статьи с тестированиями больше говорят не об участниках тестирования, а о составителе тестов. Какой специалист - такие и тесты. Очевидно, автор статьи - так себе специалист
Странно что у автора статьи и в профиле написано .net developer. И тесты притянул он за уши, и если бы повторно их запустил даже на своей программе, они бы показали другие результаты. Node.js тоже хорошая технология и очень даже применимо, но по сложности написанию кода как минимум не проще чем на c# написать (вон в его де примере кода на c# меньше нужно чем на js) а результат у . net лучше. Тут говорят про кластер, но клатер тоже вносит свой минус как в скорость, так и в стоимость, хотя если нужно на любой платформе можно кластер сделать.
@@Kulibins1 насколько я понимаю, node cluster делает ровно то, что у .net идет "из коробки" - многопоточность. Ради интереса можно пойти другим путем - урезать thread pool у .net до одного свободного потока для равных условий
11:46 Ну конечно хорошо, что он может находить мёртвый код и не исполнять его. Это полезная фича даже для нормального кода. JVM тоже так делает.
но когда это для теста используют, то наверное это не правильное сравнение.
@@Kulibins1 Да, конечно, оригинальный бенчмарк был некорректный.
ответы на ответы и переметка особенно понравились
Как-то не понятна мысль коммента, если честно.
@@Kulibins1 ты не внимательно смотрел это очевидно
Помоему давно известно, что нода хороша там, где все упирается в IO операции. Брать ноду для числодробилок - себе вредить.
Потому когда оно упирается в io, тогда и питон можно взять или что там еще медленее?
@@Kulibins1 Причем тут медленнее или нет. Как будто если весь мир не построен на .Net то значит все вокруг идиоты :) У питона из коробки не будет асинхронщины, вроде как. Или, например, нет у вас питонистов сейчас в пуле разработчиков в данной компании, это что теперь, проект останавливаем и идем питонистов искать? Не всегда и везде нужна максимальная скорость, а там где нужна можно и го с растом с таким же успехом взять.
@@dmitriyobidin6049 В нашей компании есть похоже все, и питонисты в том числе. Я все к тому что скорость разработки везде +/- одинакова если вы специалист, то одинаково быстро и качественно напишете на своей платформе код, так же как и другой специалист на своей платформе, Но если на одной платформе код быстрее работает, больше запросов обрабатывает, меньше ресурсов потребляет, то как бы это же лучше? 😉
@@Kulibins1 Я не спорю, это хорошо. Но это не единственный критерий выбора платформы для разработки. И даже не всегда этот критерий на первом месте.
@@dmitriyobidin6049 по многим другим критериям .net однозначно хорош. Например и игры делат (unity), и бэк и десктоп (хотя я от отказался, до этого много лет занимался wpf), фронт вон тоже делают (но тут я считаю что пака перспективы плохие). Код довольно надёжный (сборщик мусора ), быстрый, в некоторых случаях ультимативный и сравним с кодом на С (Rust не занимался с ним не сравниваю), всё что можно и нужно есть в библиотеках (справедливости ради сейчас во всех современных платформах все есть). Работает на всех операционках (многие наверно думают что только по виндой?, так нет под любыми линуксами тоже работает). Язык C-подобный перейти на него нет проблем ( вон все рассказывают какой питон простой, а на деле, он по сложности не уступает другим языкам). Сама платформа постоянно развивается (под ту же ноду, насколько знаю как- притихло). Какие еще у вас критерии?
Отлично! Слышал, что управление телескопа Джеймс Вебб на js написано. 😬
да можно хоть что сделать на чём угодно. но если вы хотите приблизится реалтайму, то js довольно плохо, и .net плохо, но во много раз лучше в этом плане.
Нет, js там выбран в качестве скриптового языка для коммандования системами. Т.е. там не то же, что node или v8.
Посмотрев код автора, захотелось его развидеть. Такое ощущение, что автор до этого момента писал JS только для браузера… о каком объективном сравнении может идти речь, когда код, написанный как под браузер, сравнивается с кодом, написанным под бек.
А какой вы код посмотрели? Взятый из исходной статьи?
@@Kulibins1 смотрел только тот код, который вы в GitHub выложили.
@@NickAlexandrov так там изначально код из статьи, то что я добавил 2-а теста, это с подготовкой данных для отрисовки карты, и код сравнения строк для натуральной сортировки. В тесте Фибоначчи сделал вывод значения вместо "done". Ничего координально в запуске не менял, т.к. потом скажут что из-за того что на экспресс поменял или еще что - не соответствует тому что в статье было. И просто интересно что конкретно не нравится?
@@Kulibins1 как минимум то, что в любом запросе, даже когда req.url = “/” обрабатываются и остальные if, а также создаются объекты rect, pr и строки STR1, STR2. Затем readFileSync моветон так как блочит eventloop. В /map тяжелые stringify и build выполняются в каждом запросе, хотя в этом нет смысла, затем в натуральной сортировке к строке прибавляется число и циклы while блочат eventloop пока не вернут результат. Ещё обилие генераторов прям из мира фронта всю производительность кладет на лопатки.
@@NickAlexandrov Пробовал применить express ни какой разницы. все константы вынес из функции - это дало +1.5 вызова в секунду т.е было 96.3 стало 97.8 запросов в секнду . соотношение это ни как не поменяло. И выводы ни как не изменились. Жду еще недостатки, которые изменят картину.
Было бы интересно проверить заодно низкоуровневую JS оптимизацию в виде asm.js. Механизм старый и потому новомодный синтаксис не понимает (да и с точки зрения ES5 выглядит очень не очень), но использует AOT компиляцию и позволяет использовать вычисления с целыми числами, что в сравнении с нативным кодом на double позволяет добиться ускорения в 5 раз (если сравнивать с целыми в нативном режиме то всего в ~3 раза). Правда для кода вроде чисел Фибоначчи нужно использовать рандомизацию, иначе срабатывает какой-то встроенный кэш результатов.
В node.js вообще можно добиться каких-то совершенно абсурдных оптимизаций производительности. Как то, что цикл:
for (let i = 0; i < steps; i = (i + 1) | 0) {/* Фибоначчи на целых в стиле asm.js */}
Будет на 20% быстрее чем дефолтный js цикл
for (let i = 0; i < steps; i++) {/* Фибоначчи на целых в стиле asm.js */}
Asm.js вроде как умер, есть wasm, а то что в коде | 0 как раз делает целое число
Ни те, ни другие тесты не заслуживают доверия. Слишком много факторов, вносящих замедление в вычисление. Включая даже возможный троттлинг на simd без водяного охлаждения на процессоре.
Но, конечно, вызывают жалость эксперты, на серьёзных щах рассказывающие, что жаваскрипт быстрее сишарпа.
Сравнение с жава и плюсами интересно. С жаваскриптом и питоном - нет.
Причём, я даже могу поверить что обвязка может ускорить вызов node.js до такой степени, что он обгонит .net.
Но само вычисление тут вообще ни при чём.
@@vasiliigodunov1746 кстати если посмотрите моё видео про рабочее место, то у меня водянка 😉
@@MsTim159 она вроде как умерла
@@MsTim159 Как уже написал Александр, asm.js мертв. Никто всерьез на нем не пишет (разве что какой-то легаси код), но его наследие все еще живет в JS движках (я про SpiderMonkey и V8).
Сейчас для решения тех же задач есть WASM и AssemblyScript компилируемый в него. Или Emscripten для C и C++. Также язык имеющий компилятор для LLVM потенциально тоже умеет компилироваться в WASM.
нормально нод посмоктал)
Очепятка
Все таки правильно я выбрал язык для изучения :D
Правда его я тыркаю в аспекте игростроя на юнити, но даже так ощутил его возможности по оптимизации...
👍
Будучи человеком, который чуть-чуть знаком с node/v8 internals, C#/.NET/Mono, а также с разными другими интерпретаторами, компиляторами (в т.ч. JIT/AOT), могу сказать лишь, что тесты не показательны. Что в исходной статье, что в видео. Уш прастити.
Те что мои это куски из моих реальных проектов, так что для меня они показательны.
Спасибо за интересное видео.
Очень похож на Девида Дреймана из Disturbed.
Если честно не знаю про кого говорите 😊
Класс
Наконец-то ТОЧКА .
требуется пояснее, что имелось ввиду 😉
а зачем считать фиббоначи на ноде и сортировку когда в реальной жизни на ноде таким никто заниматься не будет ибо все знают что нода для построения апи, а для математики есть другие инструменты?
Фибоначи это из исходной статьи, сортировку вставил я, т.к. у меня были видео с примером натуральной сортировки и там и там, карта тоже мой пример и тоже было видео про это. То что большая часть задачь - это элементарная прослойка между БД и фронтом, так тут всё будет в базу упираться 😁
@@Kulibins1 ну так к автору исходной статьи тоже вопрос зачем забивать гвоздь микроскопом? нода хороша для постороения апи имхо это и надо сравнивать, а если нужна математика то плюсы вам в помощь или прости господи асм
@@yuriibesedin4418 сложность написания кода на c# я бы сказал что даже меньше чем на Js, а дальнейшее сопровождение уж точно проще у C#, т.к. очень много ошибок Js отлавливаем не во время компиляции, а в рантайме. Вон даже код у шарпа компактнее, он быстрее. Тут хотя бы TS нужно использовать вместо ванильного js. Тут просто если спецу по Js нужно бэк писать, то что бы не переучиваться, то node.js выход. .net c# высокоуровневый быстрая платформа, а вот во многих других мы видим либо высокоуровневы и "медленный" либо низкоуровневый и "быстрый"
@@Kulibins1 ну на вкус и цвет все фломастеры разные. Просто если заговорили про быстродействие его бы и сравнить, а удобство написания это отдельная тема хотя я наверное соглашусь что шарп довольно передовой в этом смысле ибо они не парятся по поводу обратной совместимости как в жаве и быстро развивают язык
@@yuriibesedin4418 обратная совместимость, то никуда не делась, всё что у вас работало раньше - так и работает.
GO - такой же "тормоз"... ну или может быстрее JS, но медленнее NET (7)
С Go никогда не работал, одно время его прям продвигали, а сейчас он как бы и не популярный.
пруфы?
Я могу разогнать код CompareUnsafe и сам API на .NET 7 на порядки быстрее:
- 50.55% вызывается метод Concat
- 10.35% вызывается метод UInt32ToDecStr
- 6.69% вызывается метод Int32ToDecStr
- и только какие-то 7.90% тратится на метод CompareUnsafe
Вариантов как ускорить несколько. Но сразу напрашивается полное избавление от метода Concat и аллокации строк на каждой итерации. Далее, в методе CompareUnsafe не нужно считать num1 и num2.
Для чего здесь вообще unsafe используется? Чтобы не тратить время на проверку выхода за границы массива? Этим можно пренебречь и остаться в safe.
Еще в .NET 7 можно включить AOT или ReadyToRun. За счет этого .NET начал безоговорочно уделывать NodeJS в AWS лямбдах. Единственное место, где целесообразно сравнивать .NET и NodeJS. Теперь никакие Cold Start не помогут NodeJS.
Конечно напишите такую функцию и давайте посмотрим (без всякого сарказма). Моя функция была написана много лет назад. По поводу readytorun я тесты запускал несколько раз, поэтому не будет прям такого преимущества. И ещё я в своей функции не вижу ни каких конкатов, потом я не вижу UInt32ToDecStr и не вижу Int32ToDecStr. Мы про одну и туже функцию говорим? Как вы получили эти значения? В профилировщике производительности я их не вижу.
Чтобы переписать всю функцию API, надо знать какие изменения допустимые и какие требования к методу CompareUnsafe (ну и свободное время, чтобы написать и измерить через BenchmarkDotNet):
- строки ASCII, UTF-16LE, UTF-8 или с любой кодировкой?
- число всегда присутствует в строке?
- число всегда в конце строки?
- Может быть несколько чисел разделенных другими символами?
- CompareUnsafe должен сравнивать что-то похожее на строку?
- Пробелы, табуляции и так далее допустимы в конце строки?
- Учитывается культура или побайтовое сравнение? Учитываются диакритики?
Опишу два способа избавления от string.Concat:
1. Создать 2 буфера символов с заведомо большим размером (чтобы поместить туда строку и число) и передать 2 слайса Span в метод CompareUnsafe
2. Создать 2 двоичных буфера с заведомо большим размером (например через маршалинг) и передать Memory в CompareUnsafe
Чтобы избавиться от num1 и num2, числа не обязательно умножать на 10. Допустим есть две строки:
abc1000
abc00100
Сначала необходимо доказать, что строки одинаково начинаются. Потом, если идти с конца строки, то достаточно знать результат сравнения предыдущих символов и текущих символов, пока не закончится число. Т.е. сложность алгоритма O(n) при простом побайтовом сравнении.
Для профилирования я использовал dotTrace с профилировщиком Tracing и включенным Real time (performance counter): i.imgur.com/096OmwJ.png
Метод Concat взялся неявно из операции складывания строк:
sharplab.io/#v2:EYLgtghglgdgPgAQEwEYCwAoBBmABM3AYVwG9NcL88EAWXAWQAoBKU8yjgNwgCdcJcAXlwAiCMADGIgNzsOFbn2BDRAEwCmAMxlz5CFAE5GAgNS5gzWRg4BfTDaA
Реализация: referencesource.microsoft.com/#mscorlib/system/string.cs,3187
У числа же неявно вызывается метод ToString:
sharplab.io/#v2:EYLgtghglgdgPgAQEwEYCwAoBBmABM3AYVwG9NcL88EAWXAWQAoBKU8yjgNwgCdcJcAXlwAiCMADGIgNzsOFbn2BDcAVlkZ5lBCgCcjAQGpcwZho4BfTBaA=
Реализация: github.com/dotnet/corert/blob/master/src/System.Private.CoreLib/shared/System/Int32.cs#L80
ReadyToRun и AOT влияют только на холодный старт и JIT оптимизации. Функция прогревается в JIT через пару вызовов, поэтому в конкретном случае разница минимальна.
@@i2um1 у вас может быть профилировщик показывать и работу самого asp.net core , поэтому вы видите еще и то что написали. В моей функции нет операций соединения строки. По существу это функция сравнения для натуральной сортировки, в ней сравниваются 2-е произвольных строки, в которых могут быть (а могут и не быть числа) указанный вами пример моя функция легко сравнит. Что-то мне кажется что не напишите вы оптимальней тому что в моём примере 🤣 Нет в моём примере складывания строк, где вы его нашли? Так же нет у числа и toString (хоть явного, хоть не явного)
@@Kulibins1 создал issue на гитхабе.
Реквестирую тот же тест на Rust! 😮
Ок
Короче понятно. Что кому нравится, то и будет он(она) хвалить. Вот все вы так паритесь за производительность))) если вам хочется быстрее, то пишите на c++/c. А так рассуждения, что быстрее, на уровне переменных такое. В реальности большинство не парится о производительности, а пишут лишь бы работало. Это если уже стоит задача оптимизировать, то да. Уже начинают задумываться. А может я ошибаюсь)))
Дело не в том что хвалю что нравится, а как сказал в начале ролика: увидел статью, в которойтговорилось что нода быстрее меня это смутило, решил перепроверить - и вот результат. Далее на примере теста с сортировкой, не будет c++ быстрее, а будет тоже самое 🤣. Т.е. я могу написать на c# код который будет по производительности практически идентичным коду C. Хочу это как раз выяснить при сравнении с rust
@@Kulibins1 вы всё хорошо рассказали. Я не конкретно про вас говорю. Я в общем про комментарии. Многие здесь комментаторы пытаются доказать преимущества того или иного языка. Но ведь у одного языка есть одни плюшки, которых у другого нет и наоборот. Просто провести сравнение - интересно. А вот уже что лучше, будет спор, в котором не будет победителя. Кто-то к одному привык больше, кто-то к другому. Мне, к примеру, сложновато воспринимать работу js, с его асинхронностью, но это же не значит, что он плохой. Так же и не значит, что он хороший. Это всего лишь особенность языка. Сам я сижу на С#) Короче, комментаторы(не автор видео), не хейтите другие языки. Даже если вы думаете, что не хейтите, но на самом деле так выходит))) Надеюсь, получилось донести мысль.
@@jekaavhachev1962 я говорил что мне нравится js в виде ts. И некоторые фишки из него я хотел бы видеть в c#. Меня просто смутила статья, вот и получилось видео. А так я сам фронт делаю на Angular(ts), а не на blazor(c#). Так что все современные языки имеют своё применение и тех кто их любит.
когда сравнивают нод с си шарпом по производительности это уже уровень.. это как рнр-сты в свое время сравнивали и говорили не ну да шарп же компилируемый поэтому то быстрее но наш жмыхапэ остает совсем чуть-чуть. А вообще про многопоточность шарпа и однопоточность ноды там есть какой-то экспленейшн когда нода с одним потоком уделывает шарп видел где-то крутого нодера который норм раскидывал почему нода обыгрывает шарп но это узкий сегмент задач
Еще раз. Увидел статью где говорилось что нода быстрее. Решил проверить, т.к. а вдруг 🤣
Если сейчас все js с ts используют!
Я как бы тоже на чистом js очень редко пишу, но для этого теста специально оставил чистый JS что бы мне потом не сказали что я не то сравниваю.
А лучше взять раст и писать и быстро и удобно и безопасно
Видео с rust почти готово. Но Rust один из самых сложных языков, а результат будет в новом видео.
Спасибо за обзор, Сшарп рулит!
Всегда пожалуйста 😉
это конечно хорошо в соревнованиях "кто быстрее, выше и сильнее". а что если ты начинающий и даже года опыта не имеешь в коммерческой разработке? Половина терминов, использующаяся в комментариях и в видео кажутся чем-то неизвестным. полюбому напишу какое-нибудь унылое говно, которому никакие тесты не помогут. как быть? как развиваться, чтобы впоследствии не выглядеть тупым идиотом на фоне дискутирующих?)
У меня канал в принципе для более продвинутых разработчиков. Хоть есть и для начинающих материалы. Для начинающих очень хорошие материалы по фронту у Владилена Минина. У меня есть 2 видео про каналы которые рекомендую и там может быть что пригодится. Для бэка C# прочтите для начала книжку Рихтера (что бы понимать c# и . net), после этого можно уже мои видосики как по rest посмотреть, я почти всё что нужно рассказал.
@@Kulibins1 За книгу крайне благодарствую) На работе как раз бэк с использованием или на (понять не могу как правильно) .NET сделан. Руки все тянутся к Ангуляру. Так что кто знает, может быть недофуллстеком пополнится наш мир в будущем) Спасибо за те видео, где советовали каналы других ютуберов
@@Kulibins1 Эту книгу вообще начинающим не стоит рекомендовать, а то руку не только к Ангуляру потянутся, а еще и к пистолету)))
@@ivantut9210 Рихтера вроде про .net книгу имел ввиду. Или это у вас такое завуалированное оскорбление? 🤣
@@Kulibins1 никого не хочу оскорбить, только хотел сказать, что Дж Рихтер "CLR via c#", не для новичков совсем, может оттолкнуть вообще от изучения этого направления.
C# - сила!))
Переменную цикла в C# тоже нужно было бы сделать даблом, хотя я сильно сомневаюсь, что это существенно повлияет на результат.
Не повлияет. На операции с циклом меньше всего ресурсов тратится.
@@Kulibins1 number в JS это не обязательно double, а на усмотрениие движка. Код не идентичный получился, функция в JS на каждый запрос заново аллоцирует "rect" и "pr", проверяет req.url в каждом условии..Сортировка в JS написана максимально медленно, с созданием объекта в цикле, в то время как в C# заявлена "самая быстрая функция".
@@yoloopen если вычисления идут с double и там и там, то и тут и там будет double что бы не думал движок v8 🤣 Вынести rect и pr, ничего не поменялось. И в c# rest и pr это переменные функции main скрытой под капотом. Можете предложить свою функцию натурального сравнения (обратите внимание на слово натуральное)
@@yoloopen только что замерил если вынести все эти переменные до вызова createServer, то увеличится на 1,5 запроса в секунду, было 96.3 запроса в секунду, а стало 97.8, т.е. если честно существенно разница не изменилась, а так спасибо за совет. Для JS eсть стандартная функция натурального сравнения через localeCompare, но оно ещё хуже работает, причём заметно
Unsafe в c# - это плохая практика. Уж лучше тогда взять Rust - Actix Web. Там сразу двоичный код исполняется. Node.js в принципе не может быть быстрее с одним потоком и динамической типизацией. Расчет типов и исполнение в одном потоке как раз жирный минус ноды.
И чем же она плохая? Просто когда не умеют писать, то можно накосячить 🤣 а так это очень даже применимо. Далее есть еще simd команды они тоже есть в . net, но это еще более низкоуровнево, но ведь тоже кто-нибудь скажет зачем. Мне java разработчики говорили зачем переопределение операторов (есть в c#, нет в java), да и зачем структуры и многое другое.
@@Kulibins1 имею ввиду, что unsafe в C# нужно уметь готовить и правильно совмещать с безопасным кодом. Это мало кто может. По - этому, надёжнее разрабам написать сверхскоростной сервис на Rust и дёргать его. Это если нужны наносекунды и минимум памяти.
@@СерёгаСокольский да конечно нужно уметь. И главное нужно оптимизировать, то что тормозит, а то сколько угодно можно ускорять, то что в общий вклад вносит 1%, а то что тормозит нет.
Node.JS доступна полноценная многопоточность с shared memory. По поводу динамической типизации - она влияет только на производительность первых вызовов функции - потом функция пропускается через JIT. Но и на первых вызовах, если используются более-менее статичных структуры данных, то под капотом они представляются классами C++, и работают с соответствующей скоростью. Так что да, "на старте" Node однозначно будет уступать С#, но если дать JIT разогреться - результаты, вероятно, выровняются
@@alekseybobyr1473 .net это изначально jit. И нет не выровняются, а то не придумывали всякие wasm. Но скажу еще раз нынешний JS просто фантастически быстр и для многих задач будет достаточен. Только если писать, то уже на TS, т.к. без типизации, столько ошибок будет в проекте, даже опытные разработчики смотришь косячат на элементарном коде. Но для меня бэк это .net c#, а фронт это angular.
ну вы тоже не объективны ваш последний тест фуфло, понятно что нода позволяет запускать меньше потоков одновременно но почему вы не снизили в последнем тесте количество до 400х?
На один поток последний тест тоже огромное преимущество у кода на c#. Ссылки на код в описании к видео, можно посмотреть.
C# может быть конкурентом Java, но никак не js.
Я тоже везде это говорю, но тут в оригинальной статье автор говорит что мол смотрите какой js быстрый, быстрее c# - а это не так.
@Cosinus 0 мне кажется php уже все, доживает последние дни в Легаси проектах. Какой смысл в серверном рендеринге сейчас? Современные подходы рулят: микросервисы и фронт spa.
@Cosinus 0 Для энтерпрайза по сути только 2 варианта есть: .net или Java.
Это конторы у которых есть все свое, среда разработки, базы данных и т.п.
Больше никто не может предоставить поддержку сразу по всем направлениям. Серьезные игроки не будут экономить на спичках и брать какой-нибудь PostgreSql или MySql, возьмут готовое и нативное, все и сразу.
@Cosinus 0 ps: 🤣
Мультипарадигменность сильно бустит js (ts) в моих глазах по сравнению с С#. Плюс, когда все чем ты занимаешься на беке это ходишь в базу, вся производительность упирается во второй тест, а она в нем ровная. Какой смысл писать на менее удобном языке (литералы js - произведение искусства), который позволяет быстро с числами поиграться, если ты не собираешься с ними играться? Всю тяжелую работу можно выносить в микросервисы или сишные вставки на крайний случай (которые неплохо бы применить в самой производительной версии кода, рас уж ансейв испозьмуем. Вставки для таких случаев и нужны). Вообщем какое-то пустое сравнение, никаких интересных выводов из него не следует.
С моей точки зрения самое удобное это c#, у него гораздо больше всяких приятных фишек. В TS есть приятные моменты которых нет в c# и я их тоже хотел иметь, но в в c# гораздо больше всего, чего нет в других языках. По поводу того что только ходит в базы, посмотрите моё видео на главной странице, где я рассказываю про свою SCADA систему, посмотрел бы я как бэк SCADA написать на Js, если это и возможно будет сделать то усилия по сравнению с c# будут во много раз больше. Не все задачи представляют из себя простенькую прослойку между базой и фронтом
Смысл появляется когда задачи становятся более сложные, чем read-write в базу.
Ну, по сути, любые вычисления, любой код - это «игра с числами». Странное утверждение 🤔
Раз уж на то пошло, то node.js позволяет писать модули на С++
@@Disorrder тоже самое и на питоне, и для c# можно писать библиотеки на c++ В общем везде 😉
в шарпе больше мультипарадигмальности чем в жээсе
Нода обидится, раст позовёт, раст си шарп просто порвёт.
давай сравним, на этих же тестах.
Да только извращенцы пишут сервер на node 😁
как понял народ пишет. В прошлый раз в видео сказал что Blazor которые через wasm работает дико медленно, до сих пор у меня спрашивают а оптимизированную версию ли я сравнивал. А тут виртуальная машина .net работает по верх виртуальной машины wasm, и это медленнее чем обычный JS, причём значительно.
@@Kulibins1 А они просто собирают .Net под Wasm? По идее они могли бы некоторые гарантии рантайма переложить на сборщик мусора js, а также завязать некоторые другие рантайм фишки на JS или Wasm рантайм. Чтобы банально было ментше сборщиков мусора и так далее
@@vas_._sfer6157 не всё так просто, по другому не получится .net запустить в браузере. Но главное оно так медленно, что не имеет смысла на больших проектах. Не так критично, но и обратное js хуже на бэке.
@@Kulibins1 В любом случае это все извращение. WASM хорош и перспективен в связке с Rust
@@Kulibins1 так wasm же сильно быстрее JS.
а теперь все через mono еще прогнать бы(сервера то почти не держат на шиндовсе)
Ничего не понял? Зачем mono? .net уже несколько лет на всех линуксах работает. Вроде в видео про это говорил? У нас в проекте всё в кубер собирается с линуксовыми серверами. mono давно не актуален.
выключил на моменте тестирования в браузере на локалхосте. Ваши развенчивания мифов ни чем не лучше чем то что вы развенчиваете
Там нет тестирования в браузере!!! посмотрели бы внимательно. В браузере я лишь показал странность того что метод rest открывается по разному. А дальше идёт тестирование в JMeter. Вы не правы.
Для чего использовать var вместо double? В рекомендациях Microsoft четко написано, что var используется исключительно для анонимных типов данных. Использования var очень плохая практика. Разработчики должны внимательно смотреть на то что в правой части записи. Кроме того, в режиме отладки и релиза компилятор может использовать разные типы данных. Так зачем таким заниматься? Visual Studio спокойно предложит дополнить все базовые типы. Лично я не пропускаю PullRequest, где используют var вместо базовых типов данных.
из правой части чётко видно какой тип данных, и код выравнен а не разбегается из-за старого си-шного синтаксиса. У вас свои требования у меня свои 😉, тут главное единообразие, что бы все делали по одному принципу в одной команде.
вкусовщина. У майкрософт рекомендации каждый год на обратные меняются. они в последней версии решили в венгерской нотации вернутся и рекомендуют префикс s_ для статик филдов писать.
вар удобен, тем что всегда единообразен, плюс позволяет потом безопасно менять типы функций без изменения вызывающего кода.
ИМХО очевидное знание типа не должно быть необходимо при чтении кода.
var salesOrder = base.GetDocument()
зачем мне знать что возвращаемый тип SalesOrder (если это генерик класс к примеру) если семантика прямо это утверждает?
Особенно я обожаю такое:
SalesOrder salesOrder = new SalesOrder();
нужно больше дублицирования!
Эксплисит тайп нужен только тогда когда необходимо явное знание о типе, но очень часто это признак плохого кода:
SalesOrder document = base.GetDocument();
Не использовать var, вот что такое плохая практика.
Проходил стажировку в одной очень крупной компании, которая, если продолжит в таком же темпе развиваться скоро достигнет (лет через 5) компанию Microsoft. var - везде MUST HAVE !!! var - forever!
Шарп говнотехнология node. Js forever
🤣 потроллил, так потроллил
это, как правило, говорят те, кому не хватило мозг...в выучить .Net.
@@ivantut9210 ну это же явная подколка что бы холивар устроить (это я так политкорректно слово срач завуалировал) Не надо реагировать.
@@Kulibins1 хорошо, уговорили я точно не буду продолжать))
Дотнет мне казался всегда медленным и прожорливым
По сравнению с чем? Всегда был быстрее java, да и всего того что со сборщиками мусора. Медленным он никогда не был. А вот сборщик мусора, особенно если код плохой, уменьшает производительность, но бороться с утечками памяти гораздо легче + в .net много завязано на структуры, кода у нас что-то хранится в стеке и освобождается оно практически бесплатно. Я себе поставил в план сравнить с Rust
И да плохой код из любой платформы сделает г... о. Поэтому в первую очередь нужно писать хороший код, а потом уже будет значить платформа. Сколько раз видел всякие повторные не нужные вызовы функций или когда вместо использования специализированных структур dictionary (c#), map (Js) использовали просто массив и делали поиск по нему.