и будет тебе асинхронное выполнение

Боже

хроани Королеву

Сделай просто for с await

так с эвэйт(промисами) понятно. хочу сделать именно с генераторами

Ещё раз напоминаю, что генераторы в жс не для асинхронности

это для изучения, а не как реализация

Асинхронность на генераторах — это уже прошлая эпоха вообще)

https://github.com/tc39/proposal-async-iteration

Для изучения '''for(let promise of promises) await promise '''

Асинхронность на генераторах — это уже прошлая эпоха вообще)

тоесть ты предлагаешь для быстрого обхода массива юзать обычный цикл, если надо + промисы/асинки. Генераторы не юзать вообще для этого?

Нет

Точнее, кейс генераторов вообще в другом

Если ты делаешь кастомную итерируемую структуру, то там сам собой будет генератор

Не, у меня цель сделать мега-быстрый нормализатор данных в массиве, например массив объектов 1кк.

Достаточно обычного .map

и мне надо привести его к виду, где все объекты гарантированны имею/т правильную структуру и если не подходят - удалить

Достаточно обычного .map

мап на 1кк данных на клиентской машине?

это ж вечность будет, если он вообще не повесит его

мап на 1кк данных на клиентской машине?

Это не питон, тут всё нормально со скоростью ;)

Достаточно обычного .map

For быстрее же

For быстрее же

+++

Громкое заявление

Громкое заявление

это уже провернно-перепроверненно

иногда (ИНОГДА) быстрее оказывается while

но это случайность :)

For быстрее же

От имплементации не зависит?)

For быстрее же

В случае таких высокоуровневых замыслов с for он быстрее напишет тонну лапши

От имплементации не зависит?)

V8 точно

В случае таких высокоуровневых замыслов с for он быстрее напишет тонну лапши

Которая будет медленнее. Я согласен

Ища проблемы совсем не там откуда они придут

Не одним v8 едины

В случае таких высокоуровневых замыслов с for он быстрее напишет тонну лапши

а если б эта тонна лапши еще и быстро обрабатывалась --- было в агонь!

Пока что)

Не одним v8 едины

Другое хз. Ибо пишу под электрон, хром и ноду

Ну ок, какой кейс генератор (func*) выполняет лучше всего?

Которая будет медленнее. Я согласен

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

Ну ок, какой кейс генератор (func*) выполняет лучше всего?

Я тебе уже написал

Кастомные итерируемые структуры

Кастомные итерируемые структуры

ну таких у меня есть :) но я там генераторы не юзаю

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

Охуенно написано. Забрал себе в канал

ну таких у меня есть :) но я там генераторы не юзаю

Лоол

Нет, таких у тебя нет

У меня скоро цитатник от монады соберётся

?

ну таких у меня есть :) но я там генераторы не юзаю

Эти две фразы друг другу противоречат

by design

ок, почитаю еще

Хотя не, ты конечно можешь имплементировать iterator protocol руками, но это довольно тупо)

Хотя не, ты конечно можешь имплементировать iterator protocol руками, но это довольно тупо)

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

Хотя не, ты конечно можешь имплементировать iterator protocol руками, но это довольно тупо)

У меня есть такой знакомый. Который зачем-то многое руками пишет

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

Да не сделал ты это))

Да не сделал ты это))

а, ну ок :)

class IterableTree { parent: IterableTree leftChild: IterableTree rightChild: IterableTree data: Array<any> * [Symbol.iterator]() { yield* this.data yield* this.leftChild // (!!!) yield* this.rightChild } }

Такой объект поддерживает for of и spread оператор и разворачивает находящиеся в нём данные (свой список и списки дочерних нод) так, как будет удобнее

так генератор тоже поддерживает for..of

Кстати из этого следует один важный для твоей затеи факт

Что нормальный человеческий for of котый я тебе предлагаю с самого начала, и есть твой генератор, только в нормальной форме

так генератор тоже поддерживает for..of

Тавтология

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

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

Как опишешь — так и получается, там вообще всё на что хватит фантазии может быть)

Хоть heap, хоть double linked list, хоть что)

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

... и потом опять в массив

Это не массив

Это Iterable

ERROR: S client not available

array -> iterable -> array

изначально приходит массив, затем я с ним че-то делаю итератором, потом обратно в массив

Или я уже че-т не понимаю?

Я не решал твою задачу)

Я тебе показывал кейс в котором используются генераторы)

Я не решал твою задачу)

тебе повезло :)

Блядь

Сейчас

Я тебе показывал кейс в котором используются генераторы)

За это тебе огромное спасибо!)

Кстати, важный нюанс --- все происходит на клиентской машине

а она может быть слабая и галимая

Монопенисуально)

Монопенисуально)

)))))

Просто сделай обработку данных пачками, чтобы за раз был лаг не более установленных рамок

И в воркер их

Можно сразу в пять)

Просто сделай обработку данных пачками, чтобы за раз был лаг не более установленных рамок

чанкинг, дебаунсинг, воркеры --- все юзается

?

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

Пожалуйста, прошу простить что запоздал и уже оффтоп, но вот мне кажется, что если шатл летит не в ту сторону, то смысла в его скорости никакого. Разве не чтоб 1. Работало 2. Правильно 3. Быстро ? Т.е. оптимизации же обычно в самом конце

Если работает не правильно, то это не работает

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

а, тут под "правильно" имелось ввиду "не говнокод" наверное

Пожалуйста, прошу простить что запоздал и уже оффтоп, но вот мне кажется, что если шатл летит не в ту сторону, то смысла в его скорости никакого. Разве не чтоб 1. Работало 2. Правильно 3. Быстро ? Т.е. оптимизации же обычно в самом конце

Ну да, типо расово верные на твой взгляд подходы и прочий чисто бонусный фен-шуй

Есть какие-нибудь прогнозы по поводу релиза telegram-mtproto? @ZeroBias

А то @alpha в проекте как-то стремно Может чем помочь? Не вижу роадмап

как красиво проверить что все ключи и значения одного объекта имеются в другом?

типа f({a: 1, b:2, c:3}, {a:1, c:3}) -> true f({a:1, b:2, c:3}, {a: 3}) -> false

А то @alpha в проекте как-то стремно Может чем помочь? Не вижу роадмап

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

А то @alpha в проекте как-то стремно Может чем помочь? Не вижу роадмап

Вот это было бы хорошо конечно) ?

типа f({a: 1, b:2, c:3}, {a:1, c:3}) -> true f({a:1, b:2, c:3}, {a: 3}) -> false

лодашем