Запощу в тг

Bun не использует libuv, у них там своя реализацияна zig

🤣🤣🤣

Досмотрел до результатов. Похоже, что да. Похоже флаг нужен только когда npm script запускаешь

Чувак ну я же просил не душнить про ето (

@@DecembristITTV извини, видео интересное

Не знаю кто такой Цепкало)

@@DecembristITTV ну чел из ПрожекторПерисХилтон

Не знаю как корректно тестировать бан на нескольких ядрах

Не Aot, Дак я ж ее погрел, должна быть не медленнее чем aot как минимум

aot медленнее прогретого jit, aot лучше только в быстром запуске, т.к не нуждается в прогреве.

Любой каприз за ваши деньги)))))000))

t.me/decembristit/1304

" все данные лежат на куче в обертках, и все гоняется через байт-код" нет, вы не знаете и написали ерунду

@@user-md2fk3jj1e Не стану спорить, я с Джавой не работаю. Но может тогда лучше сразу написать как правильно, то есть не просто сказать, что написал ерунду, а сказать _почему_ сказал ерунду?

@@user-md2fk3jj1e Потому как посмотрел сейчас в интернете, там пишут что таки да, Джавовый код компилируется в байт-код, а затем исполняется на JVM; а данные хранятся в обертках на куче - ну, кроме некоторых атомарных данных, по типу чисел - но предполагаю, что в таком сложном проекте как Спринг он там сам нагенерирует кучу объектов, что будут лежать на куче. Так что хотелось бы услышать, как _на самом деле_ все устроено. Наперед спасибо!

@@AlexanderBorshak коротко не расскажешь, jvm самая навороченная vm из всех, лучше node и т.д. jit компилятор там есть с давних пор, с огромным количеством оптимизаций, умеет инлайнить методы, если в пределах финального “собранного” метода объект не улетает наружу - то легко может класть его поля в стек не создавая экземпляр в хипе. ну и на стеке кстати вы многое не сохраните, его размер не большой, а сильно переживать за хранение в куче не стоит, это не так много ресурсов требует (да и сейчас есть сборщик мусора zgc который не фризит приложение дольше 1 ms). Есть реально другая проблема, которую сейчас пытаются решить - чтобы была локальность размещения данных, как в структурах си, но изменения глобальные и подождать придется еще годик точно (но это не значит что проблема краеугольная и все тормозит из-за нее). конкретно перформарсные проблемы в тесте могут быть связаны с тем, что изначально томкат на котором крутится спринг бут (кстати через конфиг можно поменять на 2 других варианта) делался по классической модели - поток на соединение, ну и логики там точно больше чем в простеньком http сервере как в node. по-хорошему буст даст не реактивщина а виртуальные потоки, которые вышли в релиз в последней версии, но под них еще на сколько знаю идет оптимизация томката. Или сегодня видел, что есть фреймворк helidon - для тех, кому важна скорость и не особо нужен функционал.. в общем тест любопытный, но корректно было бы сравнивать фреймворки с сопоставимым функционалом, а так да, как написали ниже - это скорее тест обвязки интеграции с сетевым кодом и все что вокруг него. По хорошему стоит позапускать с профайлером, чтобы понять где узкое место и что вообще происходит. Но очевидно, что чем больше работы надо будет делать ноде, помимо перекладывания байтов в сокет - тем больше будет у ней проблем

Стабильность лучшая скорость на дистанции

Дорого переписывать

На разном пишут. В нашей компании последний год идёт переписывание сервисов с Java и node.js на Rust. Выигрыш в производительности очень значительный.

@@sky4thunder вопрос был риторический, но удачи в этом деле)

@@sky4thunder на rust нужно переучиваться. Хотя он повсеместно отвоевывает. Но его время еще не пришло. Через 2-3 года начнется хайп

Как использовать виртуальные потоки? Я не умею)

@@DecembristITTV Зависимость: implementation 'org.springframework.boot:spring-boot-starter-web' В property: spring.threads.virtual.enabled=true

Ты серьёзный?

да это будет кайф тем кто смотрит python))))@@ukratitelkisok9726

Пиши как, замерю

Потому что в проде будет именно он, если есть вопросы к его перфомансу, то это не ко мне

Вам поговорить об этом больше не с кем, Я просил не душнить, нет вы пришли все равно