AP
ну ты понимаешь что ты пробросил до верха промис? где асинхронная функция
да я понимаю что пробросил до верха промис и говорю что мне не надо каждую функцию метить как async
Size: a a a
2020 December 03
ON
такойже псевдо синхронный код получается
не, движки которые реализуют асинхронщину через итераторы - там все вызываемые ф-ии находятся на одном уровне, которые при вызове делаеют возврат следующей ф-ии в луп.
сделай пример в глубину 3, там видно будет
сделай пример в глубину 3, там видно будет
L
А что если при случайной интерации в теле функции суммы была бы асинхронная операция, мы же не всегда знаем с какими коллбеками мы работаем. В таком случае тебе придётся все вызовы оборачивать промисами. Нет?
смотри, если у тебя промис тебе его надо быросить yield
L
что бы он ушел до верха
L
а там будет await
L
если нет, то ты просто получишь в переменную promise
МТ
Если у меня есть участок кода вида:
simpleCode() // 20ms
highLoad() // 2000ms
couldBeBetter() // 300ms
logging() // 30ms
И я пишу хай перформанс, то если у меня код в couldBeBetter можно оптимизировать на 100-200мс изменением нескольких строк(плюс комментарии конечно), то я не премину это использовать
simpleCode() // 20ms
highLoad() // 2000ms
couldBeBetter() // 300ms
logging() // 30ms
И я пишу хай перформанс, то если у меня код в couldBeBetter можно оптимизировать на 100-200мс изменением нескольких строк(плюс комментарии конечно), то я не премину это использовать
МТ
С учетом того, что оптимизировать общий код нужно до секунды например
AP
а если тебе надо с этим гет работать внизу, на месте
если тебе надо будет поработать где-то снизу на месте, а потом еще что-то сделать последовательно за ним, то ты как ни старайся сделаешь новый промис для этой последовательной за ним операцией
МТ
Разве это неправильно? :)
VP
Марк Танащук
Разве это неправильно? :)
здесь речь идет как бы не про то, чтобы изменить всего две строчки
AP
смотри, если у тебя промис тебе его надо быросить yield
я начал понимать к чему ты ведешь, но это и без генераторов решается просто эвент эмиттером и на который все подпишутся, а когда промис разрезолвится эмиттер вызовут. Для этого не нужен генератор
ON
я начал понимать к чему ты ведешь, но это и без генераторов решается просто эвент эмиттером и на который все подпишутся, а когда промис разрезолвится эмиттер вызовут. Для этого не нужен генератор
не, он хочет async - await, но без async - await
МТ
здесь речь идет как бы не про то, чтобы изменить всего две строчки
Может две. Может десяток, может пятьдесят
Я скорее про сложность - если достаточно просто можно получить некий немалый перформанс(и это не превращает код в полный ад), то не стоит в хай лоад проекте этот код так оставлять.
Я скорее про сложность - если достаточно просто можно получить некий немалый перформанс(и это не превращает код в полный ад), то не стоит в хай лоад проекте этот код так оставлять.
AP
нет он говорит что каждый асинк эвейт с небольшой порцией последовательного кода пораждает новый промис, новый промис это новый тик ожидания.
L
не, движки которые реализуют асинхронщину через итераторы - там все вызываемые ф-ии находятся на одном уровне, которые при вызове делаеют возврат следующей ф-ии в луп.
сделай пример в глубину 3, там видно будет
сделай пример в глубину 3, там видно будет
let sleep = (ms, val) => new Promise(r => setTimeout(() => r(val), ms))
function* deep3(fl) {
if ( fl )
return yield sleep(1e3, 'sleep!')
return 'sync(deep3)!'
}
function* deep2(fl, fl2) {
if ( fl )
return yield* deep3(fl2)
return 'sync(deep2)!'
}
function* deep1(fl, fl2, fl3) {
if ( fl )
return yield* deep2(fl2, fl3)
return 'sync(deep1)!'
}
function* test2() {
console.log( yield* deep1(0, 0, 0) )
console.log( yield* deep1(1, 0, 0) )
console.log( yield* deep1(1, 1, 0) )
console.log( yield* deep1(1, 1, 1) )
}
asyncWrapper(test2)
AP
короче не существует такой задачи где бы эта разница производительности была видна явно, а если она будет существовать, то она решается эвент эмиттером
AP
и чтобы ощутить разницу в перформансе сколько таких deep надо?
AP
минимум тысячу наверно?