Проверяем скорость работы промисов

[kir_vesp]

Про то как V8 оптмизирует код почитайте. Ваш бенчмарк совершенно некорректен.

[ruslangavrilov]

Спасибо за комментарий. Напишите, пожалуйста корректный бенчмарк. Очень хочется посмотреть на грамотную реализацию.

[kir_vesp]

Минимально корректным будет бэнчмарк, в котором Вы в каждый промис передавали бы новую переменнную, для примера можно глянуть на бэнчмарки в репозитории.

[youlose]

Зря накинулись:
http://programmers.stackexchange.com/questions/278778/why-are-native-es6-promises-slower-and-more-memory-intensive-than-bluebird

[kir_vesp]

За ссылку спасибо, аргументация хорошая. Убеждает.

[neoxack]

Абсолютно бесполезный бенчмарк. Тестировать промисы нужно под асинхронной нагрузкой.

[ruslangavrilov]

Можете привести пример?

[vintage]

Например: https://habrahabr.ru/post/307288/#comment_9739384

[Iqorek]

Что даст «асинхронная нагрузка»? Завалит callback queue колбеками от асинхронных вызовов? На чистое время исполнения промисов, это не повлияет.

[igontarev]

впечатляет, а что на счет observble?

[Iqorek]

Object.observe? судя по всему он тоже написан на javascript и там тоже можно ожидать худших результатов, чем у аналогов.

[SDI]

Неделю назад был статья JavaScript Performance, базы данных и поиски «серебряной пули»: видеозаписи ТОП-5 докладов HolyJS 2016
В ней есть видео на доклад Вячеслава Егорова, «Производительность JavaScript через подзорную трубу»
В данном докладе объясняется почему данный бенчмарк некорректен.

И вот хорошая статься Что браузеры делают с вашим JavaScript-кодом: об оптимизациях в JS-движках на примере V8

[ruslangavrilov]

Бенчмарк поправил. Сейчас более корректно?

[Boomburum]

Немного промахнулись ответом :) SDI вам тут ответили.

[jMas]

Иногда промисы используют например в анимациях:

function show(element) {
  return new Promise(resolve => element.animate([
    { opacity: 0, transform: 'scale(.5)' },
    { opacity: 1, transform: 'scale(1)' }
  ], { duration: 250 }).onfinish = resolve).then(() => {
    element.style.opacity = 1;
  });
}

[vintage]

В собственно анимации тут промисы явно не используются.

[jMas]

Более — они и в Ajax запросах, в популярных библиотеках, тоже явно не используются. Я просто привел пример, где производительность промисов может как то повлиять на конечный результат.

[vintage]

В данном случае один единственный промис не в состоянии как-либо повлиять на анимацию.

[jMas]

show(el).then(() => hide(el)).then(() => show(el)).then(() => expand(el))...;

Например цепочка промисов. Чем больше задержка в промисах, тем дерганей будут переходы между анимациями. Но да, полагаю это не сильно существенно если промисы достаточно быстрые и доли секунды не заметны глазу.

Но не всегда асинхонная функция асинхронна. Иногда функция (в зависимости от разных ситуаций) сама принемает решение: получить данные из стороннего источника или взять уже имеющиеся в кэше и отдать синхронно, но интерфейс все равно — промис. Тогда было бы не плохо получить данные максимально быстро. Не так ли?

[Shannon]

Стараются, по крайней мере движение есть
node v6.3.1: 26.3 сек
node v6.5.0: 16.5 сек

Вообще на node 6.5.0 тест из статьи выдает такие результаты:

Bluebird
Время выполнения 14.876 сек.

Native promise
Время выполнения 16.519 сек.

[ruslangavrilov]

Странные результаты. У меня на node 6.5.0 совсем по другому. В статью добавил результаты, полученные при использовании этой версии.

[Shannon]

Первый вариант повторно

$ node prom.js 
Бенчмарк промисов выполнен!
Время выполнения 14.426 сек.
$ node prom.js 
Бенчмарк промисов выполнен!
Время выполнения 15.856 сек.
$ node -v
v6.5.0

Второй вариант:

$ node prom.js 
Бенчмарк промисов выполнен!
Время выполнения 2.7 сек.
$ node prom.js 
Бенчмарк промисов выполнен!
Время выполнения 10.404 сек.

[Jabher]

Все корректно — Петька Антонов адово крутит перфоманс, и его реализация давным-давно известна за чудовищную эффективность. А вот почему его код не перенесли в v8 — для меня большой вопрос.

[hell0w0rd]

bluebird быстрее стандартных промисов, да и прочих реализаций промисов. Это факт.
Но ваш тест, даже откинув остальные косяки, тестирует не промисы, а crypto.randomBytes. То, что происходит внутри промисов должно выполняться за константное время, чтобы протестировать непосредственно промисы.

[Andropolon]

Рекомендую еще сравнить расход оперативной памяти на промисы.
Будете очень удивлены, особенно в Google Chrome.
По нашим тестам, нативные промисы съели около 200 МБайт памяти на 100 000 вызовов.
Bluebird — что-то около 10 Мбайт кажется.