а тормознутые промисы стал бы?) где логика?

Хотя вопрос тормознутости тут явно преувеличен.

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

О каких высоконагруженных частях идет речь? На клиенте?

Речь идет о сервере.

Проработав около 10 лет с PHP у меня как-то представление о тормознутости иное. Это что-то вроде "рендер страницы на сервере 600ms долгоооо".

О каких высоконагруженных частях идет речь? На клиенте?

Не на всех клиентах можно использовать нативные промисы.

Речь идет о сервере.

А зачем на сервере компилять в while true, если можно компилять в генераторы?

А зачем на сервере компилять в while true, если можно компилять в генераторы?

Без понятия зачем babel это делал таким образом.

https://github.com/petkaantonov/bluebird/tree/master/benchmark

А есть хоть одно реальное приложение, где промисы что-то тормозят?

А есть хоть одно реальное приложение, где промисы что-то тормозят?

Подписываюсь на ответ)

Без понятия зачем babel это делал таким образом.

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

блин) Я про то, что если while(true) вас напрягает - как могут не напрягать тормознутые промисы

блин) Я про то, что если while(true) вас напрягает - как могут не напрягать тормознутые промисы

Меня теперь напрягает. Но трогать проект с ним пока не буду.

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

Дык это я уже понял.

вот прогнал сейчас бенчмарк

promises-then-promise это нэйтив?

ой не, глупость написал)

и тут глупость

promises-ecmascript6-native.js - вот нативные

сейчас тоже попробую

что плохого в while(true) {} ?

любой event loop так работает

v8 такой код не оптимизирует, вроде

сейчас тоже попробую

npm i && ./bench doxbee

Начал смотреть в код бенчмарков блюберда. Глаза вытекают, они всюду глобальные переменные юзают

Откуда здесь берутся parallelQueries? https://github.com/petkaantonov/bluebird/blob/master/benchmark/madeup-parallel/promises-bluebird.js

все что я могу сказать - автор признаный perf задрот, у него есть неплохая статья про производительность в v8

Помимо перформанса код еще поддерживаемым должен быть, мы же не на олимпиаде

https://github.com/petkaantonov/bluebird/blob/5bffd55f20f1df5361603612867f286fa13e56e3/benchmark/performance.js#L37

это бенчмарк и это опенсорс) Возможно сделай он по другому - это влияло бы на перфоманс)

что плохого в while(true) {} ?

плохого ничего нет, если это не приложение под нагрузкой

из-за этого на фронте

это норм, на беке, смотря для каких целей и нагрузки

https://github.com/petkaantonov/bluebird/blob/5bffd55f20f1df5361603612867f286fa13e56e3/benchmark/performance.js#L37

Ужас какой

Какой-то бесконечный бенчмаркинг

это бенчмарк и это опенсорс) Возможно сделай он по другому - это влияло бы на перфоманс)

И как бы это вляло на перформанс если бы он заранее рекваерил?

10к раз все тесты запускаются)

10к раз все тесты запускаются)

Я уже понял, поэтому запустил на сервере.

И как бы это вляло на перформанс если бы он заранее рекваерил?

я не задрот перфоманса. Мне просто нравятся быстрые, более полные функционально решения. Поэтому мне нравится bluebird.

2 скрина бенчмарков как бы это все подтверждают)

Сейчас еще на 6-й ноде попробую.

А то тоже как-то уныло

Я лично верю что блюберд быстрее, мне интересно как это возможно

А чего тогда node team bluebird не взяли в качестве нативной либы?

@AGambit на сколько понимаю, дело не в while(true){}, а используется ли эффективно event loop

ага, там 5 v8, вдруг они улучшили) А хотя погодите... нет)

да

и просто в расходе памяти на это

Есть подозрение, что блюберд не по спеке работает и в том же тике промис резолвит

на сколько я знаю node вообще ничего из стандартной библиотеки, кроме таймеров не переопределяют

плюс в ядре ноды нет промисов

плюс в ядре ноды нет промисов

Промисы в v8

я имею ввиду они не используются

поэтому ноде и нет смысла их переопределять

все по спеке)

Так насколько я знаю, promise на самом же JS написан

+ туча удобных методов вроде map/filter/each/get/spread/etc.

вот именно это и удручает) как команда v8 умудряется так писать - не понятно

+ туча удобных методов вроде map/filter/each/get/spread/etc.

почти уговорил

Потому что смузи, ковокинг и все вот это)

Можете у славы егорова в твиторах спросить почему нативные промисы медленнее

и вишенка - у метода map есть concurrency опция. Чтобы не 1000 запросов слать, а по 5. как queue в async, или как-то так

мне вполне понятен ответ Листочкина. Сначала они делают 100% покрытие es2015, а потом работают над перфомансом

callback'и наше усе!

34% оверхеда на async/await относительно колбэков. Мне кажется это очень неплохо)

убедил?)

Ну практически. Если я правильно посчитал, то 100 нейтив промисов это около 10ms (если брать серверный результат бенча). Что как-то огорчительно для меня :(

А я тоже иногда люблю позадротстсовать с циферками...

хэй, час, а я правильно понял, что в следущем LTS ноды будет async/await?

интересует "точно"/"не точно"

Следующий LTS = 6, а пока еще в 6 нет их (так что совсем не точно)

прочитал про осень что-то

По идее там lts через 1 мажорный идут. То есть 4,6,8

Так что в след мажорном, видимо. Но не лтс

ES Modules, async/await в Chakra https://twitter.com/MSEdgeDev/status/732616955560005634

У меня в связи с этим два вопроса. Когда нам ждать ES Modules в v8? Кто то пытался использовать node на chakra?

и как там реализованы es modules ? как они грузятся?

@vmakhaev Разве ядро ноды абстрагировали, чтобы она могла использовать и чакру, и v8?

Как в чакре сделали модули это очень хороший вопрос

В блоге немного объяснили, но не все

<script type='module' src='./app.js'> - хм, то есть если не указать type уже не будут работать импорты? Но да, инфы мало и нужно будет сегодня дома протестить на edge

Там был PR от Microsoft и как я понял пока это форк ноды с поддержкой чакры. https://habrahabr.ru/post/276617/

но вроде как в итоге завернули, или я не видел способов запуска node.js на chakra

хотя вот репозиторий - https://github.com/nodejs/node-chakracore но что бы собрать, нужна win машина и Visual Studio -_-

вот-вот

не видел, чтобы пулл-реквест с добавлением чакры в ноду взлетел =(

6.2 вышла. По первой пробе - проблемы, которые у меня появились на 6 версии - отвалились)

6.2 вышла. По первой пробе - проблемы, которые у меня появились на 6 версии - отвалились)

а какие были проблемы? я только заметил снижение скорости работы с массивами

а какие были проблемы? я только заметил снижение скорости работы с массивами

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

злые языки говорят, что если с ноды на go перейти, то всё становится значительно быстрее, и в 3 раза меньше памяти жрёт http://blog.scaledrone.com/posts/nodejs-to-go

10-15мб ram

это на процесс?

да, на голый процесс, без аллокации больших данных в памяти (in-memory cache) и прочего, у нас микросервисы, после оптимизаций выходит по 20-30 мб на каждый, те, что работат с фронтом: 200-1000 мб (держат websocket соединения)

https://habrahabr.ru/company/mailru/blog/283228/

Это очень даже радует. А как по ощущениям трудозатраты отличаются?