Callback / Promises / await — что быстрее и экономичнее?

Question

[Смотритель]

Приветствую.

С ES6 появились промисы, в ES7 добавлены async/await - всюду публикуют рекомендации отказываться от callback-ов т.к. это понятнее и синтаксически "правильнее", но в то же время противоречивые данные по принципам работы (в целом пишут, что промисы и асинк/авайт - это "сахар").

В текущем проекте так складывается, что синтаксически вложенности более 2-х уровней колбеков нет и не будет, однако есть несколько модулей, требования к которым по скорости работы и затратам памяти очень "жестокие". И в первую очередь это связано с "замыканиями" и соответственно динамическим выделением памяти/ее очисткой + создание/удаление самих функций-обработчиков. Объекты местами довольно "тяжелые" и очень хочется максимально избежать лишних операций.

Соответственно вопрос - что же все-таки использовать правильнее в таких условиях (ведь если промисы и асинк/авайт только "сахар", то помимо накладных расходов от колбеков добавляется еще и эта "сахароза")? И почему?

И да, к слову, ситуация складывается так, что все это добро оформлено в классы и присутствует "условие" непредсказуемого количества повторений, что-то вроде (в синтаксисе async / await - так реально максимально понятно просто, если текущий вариант на колбеках постить, будет длинный и непростой код):

class a {
  async updateMovies() {
    let v = ....;
    while (await a(v)) {
      ... тут повторяемый код метода
      ... некие операции с "v"
    };
    ... тут код завершения метода
  };

  async a(v) {
    ...
  };
};

Answer 1

[Leo Developer]

Если для вас производительность так критична, пишите на базе, т.е на колбэках.
Если для вас встроенный метод массива, для фильтрации элементов критичен по производительности, пишите алгоритм.

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

Comments

[Смотритель]

Да, производительность тут первична, и самый наилучший вариант "реализовать на компилируемом языке" пока недоступен... Спасибо за мнение - пока тоже к нему склоняюсь, только остается вопрос выше, продублирую тут:

class CLS {
  asyncFn(v, fn) {
    ... некие асинхронные действия
    v.v1 = ......;
    v.v2 = ......;
    fn();
  };

  asyncRes(v) {
    ...
  };

  data(v1, v2) {
    const v = {v1: v1, v2: v2};

    // и вот тут и доп.вопрос
    this.asyncFn(v, () => {
      this.asyncRes(v);
    })
  };
}

метод data() вызывается крайне часто, в среднем 5000/сек доп вопрос заключается в том, что каждый вызов мало того, что создает объект "v" (но благодаря тому, что мы используем объект, то пробрасывать параметры/результат и переопределять отдельно значения не требуется - просто работаем прямо с объектом сразу, т.к. он передается по ссылке)...

но выходит, что при каждом вызове this.asyncFn(...) создается и анонимная функция, цель которой тупо вызвать другой метод класса, чтобы можно было работать через this... просто передать

this.asyncFn(v, this.asyncRes);

нельзя, т.к. при вызове теряется контекст класса и this будет недоступен в методе...

Вот есть ли вариант как-то это реализовать все-таки без создания этих бестолковых (анонимных "пустых") функций?

[Leo Developer]

Артем, Есть, в конструкторе класса сделай типо того:
this.asyncRes = this.asyncRes.bind(this)

Тут у тебя создается функция которая вызывает asyncRes c контекстом this. И функция будет создаваться только один раз

[Смотритель]

эмммм, точно именно так? или имя "алиаса" нужно другое задать и потом его юзать?

class CLS {
  constructor() {
    this.asyncResBind = this.asyncRes.bind(this);
  };
  ...
  data(v1, v2) {
    ...
    this.asyncFn(v, this.asyncResBind);
    ...
  };
};

[Leo Developer]

Артем, Точно именно так

[Смотритель]

Вот спасибочки, а то я уже всю голову сломал, как передавать метод-обработчик в качестве функции колбека так, чтобы не было созданий этих анонимок-коротышей...
Текущий код вообще реализован в таком формате, что в замыканиях не только рабочие переменные, и они же передаются в параметризации колбеков, но и создается постоянно "алиас"-замыкание... и вот представляете, что там происходит, когда идет вызов data() десятки тысяч раз в секунду, тогда как примерное время выполнения с "входа до выхода" около 2-3х секунд (соответственно столько времени живут все эти замыкания и вновь создаваемые функции со всеми вытекающими последствиями в том числе у мусорщика)...

data(v1, v2) {
  const self = this;
  ...
  this.asyncFn(v1, v2, function(res) {
    self.asyncRes(v1, v2, res);
  });
  ...
};

[Leo Developer]

Артем, Не за что. И вам спасибо

[Смотритель]

Leo Developer, а вот тоже вопросец, вариант "создания алиаса" в конструкторе + указание этого алиаса в качестве колбека, можно ли заменить на прямое указание с bind(...)?

Ну т.е. использовать сразу:
this.asyncFn(v, this.asyncRes.bind(this));

Это будет по факту "созданием одноразовой функции" или нет?

[Leo Developer]

Артем, В таком случае у тебя будет каждый раз создаваться новая функция

[Смотритель]

Leo Developer, понял, значит лучше через конструктор, спасибо еще раз!!!

Answer 2

[Сергей Горностаев]

Соответственно вопрос - что же все-таки использовать правильнее

То, что делает код чище, понятнее и проще для сопровождения. А это async/await при прочих равных.

если промисы и асинк/авайт только "сахар", то помимо накладных расходов от колбеков добавляется еще и эта "сахароза

Не добавится. Весь сахар растворится при парсинге скрипта, в AST его уже не будет.

Comments

[Смотритель]

Если этот "сахар" реально не влияет и "растворяется", то почему при сравнениях нативных промисов и их реализации в bluebirds дают очень разные результаты и по скорости выполнения и по потребляемым ресурсам. Значит все-таки реализация этого "сахара" оказывает какое-то влияние?

[Сергей Горностаев]

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

[Смотритель]

Сергей Горностаев, с этим согласен, но вопрос все-равно ведь остается... Если реализация промисов "родная" и "чужая" дают разные "показатели", то получается, что все-таки это не совсем "расворимый сахар"? И тогда возвращаемся к вопросу - насколько этот сахар лучше чистых колбеков или хуже не в плане синтаксиса, а именно в плане производительности и потребении памяти (особенно то, что касается замыканий)... В примере выше с обычными колбеками переменную вообще лучше выносить в свойства класса, чтобы с ней можно было нормально работать (хотя по сути своей она там нафиг не нужна болтаться, к тому же может быть и конфликтная ситуация, если updateMovies() будет вызвана как бы "параллельно" несколько раз), тогда как на async / wait она вполне хорошо себя чувствует в методе класса...

[Сергей Горностаев]

Артем, совсем растворимый, просто разворачиваться может в разные конструкции. Правильнее всего было бы посмотреть результирующий AST или даже байткод, чтобы найти ответ.

[nrgian]

Артем,

то получается, что все-таки это не совсем "расворимый сахар"?

Возможно, что речь шла о режиме поддержки совместимости по старыми версиями JS?

[Смотритель]

nrgian, я не знаю, к сожалению... Антон ниже верно написал, что требовательные по ресурсам/скорости вещи лучше писать не на JS, но что досталось, с тем и работаем =(((
Была еще мыслишка самые узкие места переписать в какие-нибудь модули на чем-то компилируемом, но пока решили попытаться пойти по пути оптимизации кода, ну а если не получится, тогда уже думать о другом ЯП...

Answer 3

[Антон Швец]

Да, есть небольшой оверхэд от промисов, но выгоднее писать понятный код и купить плюс одну виртуалку, чем экономить на спичках и утонуть в аде коллбэков



Если у вас там ничего сложного, используйте коллбеки, в разумном масштабе ничего страшного. Но обычно, если требования к скорости суровы, берут не js, а компилируемый язык модный типа golang или модуль на C/C++ пишут.

Comments

[Смотритель]

Да, там колбеки не больше 2-х уровней вложенности, причем часть из них проще и гораздо лучше перевести из варианта вложения в вариан вызова метода, тогда получается вообще один уровень.
Но меня в данном случае волнует еще и такой момент, как замыкания - с переменными, которые нужны в обработчиках колбеков, но в то же время и нужны на уровне выше.
С вариантом async как видите, все гораздо проще и предположительно выгоднее "по памяти", хотя х.з. что там под капотом получается, может и там тоже черти что...

[Антон Швец]

Артем, await просто упаковывает все что ниже него в коллбек для then и область видимости точно так же попадает в замыкание для этого коллбека. Но это же те же самые переменные, если на них нет больше ссылок, GC уберет их.

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

Есть еще такой момент - промис ловит исключения. Если в вашем коллбеке вылетит неприученный к лотку эксепшн, приложение рухнет. А промис только ворнинг в консоль напишет. По этой причине не советуют мешать коллбэки с промисами, где-нибудь да пропустишь, а дебажить такое порой тяжело.

[Смотритель]

Ок, тогда Антон, чисто "лабораторный" вариант, подтвердите или опровергните меня, плз.

class Test {
  constructor() {
    this.s = "a";
  }
  a1(str, fn) {
    str += this.s;
    fn(str);
  };
  b1() {
    let t1 = "12";
    this.a1(t1, (r1) => {
      console.info(t1); // 12
      console.info(r1); // 12a
    });
  };
}

тут получается, что сначала выделяется память с замыканием под t1, потом при вызове this.a1 она "клонируется" (т.е. выделяется снова память), дальше с ней операции выполняются и выполняется вызов колбека и снова получаем еще одно выделение памяти под переданное значение r1

Будет ли польза, если, например, заменить t1 = "12", на объект, например t1 = {"val": "12"} - по идее ведь тогда передача должна быть не по значению, а по ссылке, и тогда выполняемые действия с t1.val в методе a1 должны выполняться с той самой областью памяти, которая была выделена в методе b1.

class Test {
  constructor() {
    this.s = "a";
  }
  a1(str, fn) {
    str.val += this.s;
    fn();
  };
  b1() {
    let t1 = {"val": "12"};
    this.a1(t1, (r1) => {
      console.info(t1.val); // 12a
      console.info(r1.val); // 12a
    });
  };
}

Мое предположение верно? Этот "хак" может помочь при работе с памятью? И как сборщик мусора с таким будет работать?

[Смотритель]

Отвечаю на свой же вопрос...

Действительно при передаче в колбек переменной как объекта (т.е. по ссылке) работа с ней в колбеке происходит напрямую с исходной областью памяти. Это радует и дает надежду заменить передачу набора переменых в вызовах на один объект из этих переменных и обрабатывать их без всяких дополнительных выделений областей в памяти под "дублирующиеся" данные =)

Т.е. лучше использовать вместо:

function fName (var1, var2, var3) {... работаем с var1, var2, var3 ... }

передачу объекта с полями:

function fName (vars) { ... работаем с vars.var1, vars.var2, vars.var3 ... }

И если нужно менять исходные var1,2,3 то в первом варианте нужно вернуть из функции новые значения как результат (а с учетом того, что переменных несколько, то возвращать придется объектом, поля которого опять же копируются из переменных - опять имеем выделение памяти), во втором варианте значения меняются прямо в функции и вообще возвращать ничего в принципе не требуется.

[Антон Швец]

Артем, на самом деле, когда вы передаете в функцию '12' ничего никуда не клонируется, строка существует в памяти в единственном экземляре, и функции будет передана ссылка на эту строку.
Но если вы попробуете значени строковой переменной изменить, то будет создана новая строка и в переменную запишется ссылка на эту новую.
Строки, и вообще примитивы, в js иммутабельны.
Причем, если вы сделаете две строки, например str1 и str2 по 100 мегабайт, и потом сделаете str1 + str2, то потребляемая память не увеличится вдвое, строки будут храниться по прежнему кусками.

Но это не точно, я не знаю js настолько, чтобы утверждать наверняка. Просто делал тесты.

[Смотритель]

Антон Швец, к сожалению нет =(((
в этом плане мне очень нравится старый добрый C, где в функцию можно передать конкретно или сам объект/строку/число и т.д. или ссылку на него, сделать именно так, как нужно...

А пример с str1 + str2 - вы правы только отчасти... именно в таком формате "str1 + str2" - действительно ничего не изменится, т.к. это просто операция, результат которой никуда не сохраняется, но если добавить до "str3 = str1 + str2", то ситуация резко изменится, потребление памяти увеличится

[Антон Швец]

console.log('empty heapUsed:', process.memoryUsage().heapUsed);

const str1 = Array.from(Array(100000), () => Math.random().toString()).join('');
console.log('str1 heapUsed:', process.memoryUsage().heapUsed);

const str2 = Array.from(Array(100000), () => Math.random().toString()).join('');
console.log('str1 and str2 heapUsed:', process.memoryUsage().heapUsed);

const str3 = str1 + str2;
console.log('str1 + str2 heapUsed:', process.memoryUsage().heapUsed);

setTimeout(() => console.log(str1, str2, str3), 1000000000); // чтобы gc ничего не сожрал

[Смотритель]

Антон Швец, да, вы правы =)

действительно, пока не выполняются какие-то операции с переменной, которая получена путем соединения двух других память особенно не увеличивается - только немного, но если сделать вместо const str3 поставить let str3 и потом попытаться изменить значение str3 - то память подскакивает.

Признаю, при простых операциях действительно большого выделения памяти не происходит =)

[Антон Швец]

Артем, плохо прочитал то, что я написал выше.

Нельзя изменить значение str3. Вообще. В str3 записывается ссылка на объект-строку в памяти, и это и есть "значение". И когда мы что-то немножечко меняем в str3 в памяти создается новый объект.
Если в коде нет больше ссылок на компоненты str3, то GC очистит память, но у нас есть str1 и str2 и они будут хранить части старого str3, поэтому память и увеличивается.

Когда говорят что примитивы в функцию передаются по значению - нам врут.
В js (как и в питоне) все передается по ссылке, просто объект можно изменить изнутри, а примитив нет. Создается новый примитив, поэтому указатель, существующий в скоупе функции меняет свое значение, а исходный указатель по прежнему указывает на исходный объект.

console.log('empty   heapUsed:  ', process.memoryUsage().heapUsed);

const str1 = Array.from(Array(1000000), () => Math.random().toString()).join('');
console.log('str1    heapUsed:', process.memoryUsage().heapUsed);

const str2 = Array.from(Array(1000000), () => Math.random().toString()).join('');
console.log('str1,2  heapUsed:', process.memoryUsage().heapUsed);

const str3 = `${str1}${str2}`;
console.log('str3    heapUsed:', process.memoryUsage().heapUsed);

const str4 = str3.slice(1000000);
console.log('str4    heapUsed:', process.memoryUsage().heapUsed);

[Толстый Лорри]

Есть подозрение, что в примере на картинке виноват не коллбек-хэлл, а просто код в индийском стиле. Итерация по массиву строк была бы компактнее и читабельнее.

[Антон Швец]

Толстый Лорри, да это ерунда. Добавим в коллбеки логику, например.

[Антон Швец]

Артем, кстати, стоит добавить в пример строки чуть по длиннее, например из Array(13000000) и ситуация меняется :)
Не могу объяснить почему, может js начинает сжимать строки в памяти при приближении к пороговому размеру (строка и буффер не могут быть больше 2гб на 64битной системе).

empty   heapUsed:   4921120
str1    heapUsed: 1368583576
str1,2  heapUsed: 1443555848
str3    heapUsed: 1443560880
str4    heapUsed: 954802728

[Смотритель]

Антон Швец, еще интереснее себя ведет нода, если вызвать функцию, которая в свою очередь получает переменную из параметров, потом ее передает в другую функцию + анонимную функцию-колбек, которая в свою очередь вызывает этот колбек, и тут уже память скачет, хотя по сути вышенаписанных тестов не должна бы =))) операции те же самые...

[Толстый Лорри]

Антон Швец, тогда это уже нужно выносить в отдельную функцию.
Простыня похожего кода - это плохо, вне зависимости от технологий.

[Антон Швец]

Артем, нужен пример
Толстый Лорри с именованными функциями тоже не подарок. Тяжело читать код, написанный как множество
именованных колбеков, тяжело его писать правильно.
Линейное полотно из промисов воспринимается проще.

[Смотритель]

Толстый Лорри, Вот и я тоже так думаю, но тут второй вопрос встает:

class CLS {
  asyncFn(v, fn) {
    ... некие асинхронные действия
    v.v1 = ......;
    v.v2 = ......;
    fn();
  };

  asyncRes(v) {
    ...
  };

  data(v1, v2) {
    const v = {v1: v1, v2: v2};

    // и вот тут и доп.вопрос
    this.asyncFn(v, () => {
      this.asyncRes(v);
    })
  };
}

метод data() вызывается крайне часто, в среднем 5000/сек доп вопрос заключается в том, что каждый вызов мало того, что создает объект "v" (но благодаря тому, что мы используем объект, то пробрасывать параметры/результат и переопределять отдельно значения не требуется - просто работаем прямо с объектом сразу, т.к. он передается по ссылке)...

но выходит, что при каждом вызове this.asyncFn(...) создается и анонимная функция, цель которой тупо вызвать другой метод класса, чтобы можно было работать через this... просто передать "this.asyncRes" нельзя, т.к. при вызове теряется контекст класса и this будет недоступен в методе...

Вот есть ли вариант как-то это реализовать все-таки без создания этих бестолковых функций?

[Толстый Лорри]

Антон Швец, напротив, именование упрощает чтение, сразу объясняя "что это делает?" вместо самостоятельного анализа и выведение смысла из императивного кода ("как это происходит?").

Линейное полотно из промисов воспринимается проще.

Оно остаётся дурно пахнущим полотном. Просто другой сорт, как говорится (=

Проблема ада коллбеков не в полотнах, а в лапшеподобном хитросплетении их пробросов с помощью замыканий (JS никак не ограничивает доступ к переменным из внешней лексической области, как это реализовано в том же C++).

[Смотритель]

Антон Швец, если юзать async / await - то вообще легко читается, но опять же - вопрос в "накладных" доп расходах, которые и реализуют это удобство чтения, будет ли результат не "УДОБНЕЕ", а "БЫСТРЕЕ и ЛЕГЧЕ (по памяти)"...

[Антон Швец]

Артем, не будет. Но заметить это будет непросто.

[Антон Швец]

Толстый Лорри, только недавно дебажил код с 10 последовательными именованными колбеками, в каждом от 1 до 10 строк. Замучаешься бегать, их названия не добавляют ясности, просто очень много названий на каждый чих.
Переписал как два асинк метода, в экран поместилось, все последовательно и понятно из названий и логики.
Библиотеку async в свое время не от хорошей жизни использовали.

Кроме того, неплохо бы каждую функцию пояснять с помощью jsdoc, понятно что у нас будет с коллбеками.

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

[Смотритель]

Антон Швец, вот и я про то же... есть сильные опасения, что не просто асинк и промисы не улучшат ситуацию, а скорее ухудшат... и по поводу "заметить" - на штатной нагрузке в 5-10к/сек вызовов это не проявит себя, но на пиковых более 500-700к/сек - это станет очень заметно...
Собственно текущая лапша и дала знать о своих проблемах именно на пиковых нагрузках, а как известно именно они становятся предпосылкой для рефакторинга =(((

[Толстый Лорри]

Антон Швец,

код с 10 последовательными именованными колбеками

Переписал как два асинк метода

Опять же, дело не в коллбеках (= Нужно было хорошенько порефакторить.

Библиотеку async в свое время не от хорошей жизни использовали.

Я не говорю, что промисы с авейтами - это плохо. Просто пример на картинке мне кажется плохим (не показательным) мотиватором.

неплохо бы каждую функцию пояснять с помощью jsdoc, понятно что у нас будет с коллбеками.

Много комментариев в коде - тоже плохо. Документировать имеет смысл только торчащие наружу вещи. Для остального есть просто выразительные названия.

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

Отличное решение, я считаю.

[Антон Швец]

Артем, ну я уже же сказал, коллбеки всегда будут быстрее, промис это удобный способ вызвать коллбек и структурировать код.
Перепишите, но тот 1% производительности вас не спасет.

[Смотритель]

Антон Швец, да переписывать-то все-равно придется =)))

Answer 4

[sh84]

async синтаксис безусловно выигрывает по читабельности и простоте.
Будет ли значимый выигрыш при использование callback-ов - можно выяснить только с помощью тестов производительности и/или профилирования.
По моему опыту с 90% вероятностью окажется что разницы нет.

Answer 5

[Дмитрий Макаров]

по идее разница все равно не велика должна быть. попробуйте так и так написать участок и запустите тесты произволительности, будет однозначно ясно.

Comments

[Смотритель]

Слишком накладно пробовать =))) суть как раз в том, что все сейчас на колбеках написано, но написано реально "адово", и складывается ощущение, что основные потери идут как раз по двум пунктам:
- постоянное создание/удаление функций-колбеков (местами стрелочные, местами простые анонимные)
- собственно большое количество переменных и констант в замыканиях
и есть еще пока только предположения, что эти замыкания не всегда чистятся сборщиком мусора, и соответственно со временем выедают память (в сутки примерно полтора-два гига уходит)...

Вот и волнует вопрос - все эти промисы/асинки реально "обертка" обычных колбеков, со всеми сопутствующими доп. расходами по памяти/процессору или все-таки некая реализация, которая лучше работает с памятью хотя бы...

[Дмитрий Макаров]

Артем, а может стоит переписать этот оверхед? на разбить аккуратно. избавиться от утечек и чтоб было приятнее читать.
кстати есть такой опыт у меня есть приложение на ноде 8.15 написано как раз async,await при запуске сьедает 115 мб., плюс минус. как то через пол года посмотрел, аптайм рельно был полгода. и занимала те же 115 мб. я аж удивился что js/нода не имеет утечек.

[Смотритель]

Дмитрий Макаров, да кто ж против-то =))) по хорошему некоторые части вообще стоит переделать целиком и желательно на другом языке, поддерживающем многопоточку + асинхронку - но пока для таких глобальных переделок времени нет - начинать приходится с малого...

Answer 6

[profesor08]

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

// долго, так как сначала ждем а, потом б
// если на выполнение каждого надо по 5 сек, итоговое время выполнения будет 10 сек
async function sum(a, b) {
  const a = await getA();
  const b = await getB();

  return a + b;
}

// быстро, так как создали по промису, и они одновременно обрабатываются, потом только ждем их результатов.
// если на выполнение каждого надо по 5 сек, итоговое время выполнения будет 5 сек
async function sum(a, b) {
  const a = getA();
  const b = getB();

  return await a + await b;
}

Comments

[Смотритель]

Эээээ... о браузерах никакой речи нет, это чисто NODE-вский сервис, браузеры тут никаким боком...
И вопрос совершенно не о том, как удобнее - самый удобный вариант с async/await с точки зрения именно синтаксиса.
Но не всегда то, что удобнее - лучше по производительности.

Самый простой пример из моей практики был такой: на вход подавался очень длинный массив чисел в строковом виде и выровненный по длине ("1234", "0023", и т.д. - для понимания), нужно было вернуть отсортированный массив. Так вот просто по синтаксису сделать просто Array.sort(....) оказалось по времени выполнения почти в 3 раза дольше, чем выполнить ту же самую операцию в три шага: сначала привести весь массив к числовым значениям, потом отсортировать числа, и потом по результату пройти и привести снова к строкам элементы с выравниванием по длине... Если смотреть по коду - покажется, что идиотизм туда-сюда гонять типизацию, а по результату - более быстрая работа, а при массивах в 100-200 тыс элементов это оооочень сильно заметно было.

Было наблюдение, которое дает о себе знать именно при большом количестве повторений. Есть метод, который дополняет строку до определенной длины (padEnd или padStart) - так вот использование этого метода для получения результата по выполнению более чем на 50% дольше по времени, если взять и к строке просто прицепить "с запасом" строку из символов заполнения, а потом применить обрезку...

Так вот и тут то же самое - важен не столько синтаксис (в конце концов вынести в отдельный метод колбек не проблема, чтобы избежать глубокого вложения), да сложнее для понимания... Тут в первую очередь важны затраты - пока мои опасения подтверждаются, что по сути промисы и асинки - это только "обертка" вокруг простых колбеков, т.е. все их проблемные места (затраты на создание/удаление анонимных функций, замыкания и т.д.) присуствуют, а к ним еще и накладные расходы на этот сахар добавляются (который более или менее "сладкий" в зависимости от реализации - нативные промисы или Блюберд дают разные результаты).

[profesor08]

Артем, промисы это не про синхронные операции сортировки строк. Это асинхронные операции. Большую часть времени занимает ожидание выполнения некой операции (получение ответа от куда-то). Ну, а если ты в них просто делаешь синхронные вещи, то зачем тогда промисы?

[Смотритель]

profesor08, а я сказал где-то что в промисах синхронные операции выполняю?
Попробую другими словами - любой код можно выполнить нескольими способами, какие-то будут быстрее, какие-то могут лучше с памятью работать, какие-то нечто среднее...
Работа с колбеками - скажем так отправная точка для оценки... Там есть расходы на память, на замыкания, на создание/удаление функций и т.д.
Промисы и await - судя по тому, что выше написано, только лишь сахар (обертка) над колбеками, соответственно это дополнительные операции/расходы ресурсов при выполнении... Когда речь идет о том, чтобы выполнять просто некие длительные операции изредка - это одно, но когда ситуация такова, что в секунду может быть до миллиона вызовов методов, которые порождают выполнение асинхронных операций, соответственно создание колбеков и замыканий и всего сопутствующего, вот тогда любые мелочи уже начинают влиять, в том числе и работа "мусорщика" тоже может сказываться - т.к. при таких активных действиях по созданию/"удалению" функций, замыканий и т.д. время очистки увеличивается, это сказывается на операциях, которые нужно выполнять в это время и они задерживаются, что вызывает свои геморои...
Повторюсь - речь не про браузерный код, а про один из сервисов на NODE (к сожалению, какой-то очень ушлый модератор удалил тег Ноды из вопроса, тем самым внеся дезинформацию)