у людей перегрузка инфы наоборот, имхо

Что быстрее двойной for или двойной reduce?

Тебя это волновать не должно

Настало время экономить на спичках

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

Я сейчас оптимизирую по скорости модуль pipe / compose

Для ощущения разницы for / reduce приходится давать серьёзную нагрузку

а я картинки сжал

Что быстрее двойной for или двойной reduce?

Бенч @ отвечай

а я картинки сжал

Я не в плане того что проект ускоряю, я просто делаю самую быструю реализацию pipe / compose и поэтому зависаю в бенчах

Самая быстрая по сравнению с чем

Жкверийным?

Самая быстрая по сравнению с чем

Реализации в redux, Ramda и lodash уже обогнал

Очень круто на самом деле осознавать что смог обогнать лодаш))

И сколько минимум нужно данных чтобы увидеть разницу?

Compose длиной в типичный редакс стейт

Что быстрее двойной for или двойной reduce?

Lodash flatten для объектов есть?

Но я пока рассуждаю в op / sec, а человеческие выводы пока только в процессе

Пока расклад такой

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

что-то мне кажется, что производительность может меняться, причём довольно значительно в зависимости от JS движка

Да

Три этапа — определиться с наиболее быстрым подходом, сформировать наиборее реалистичные бенчи, оптимизировать на различных движках

Вот я пока на втором этапе

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

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

Ты о производительности не должен думать вообще

например делать упор на производительность в мобилках

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

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

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

Есть ещё задачи nodejs

Есть ещё задачи nodejs

Где слабыми местами обычно является дисковый и сетевой ввод-вывод.

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

опять же лучше сначала думать о хорошем интерфейсе модуля

Сильно от задач зависит всё это

Чаще не нужно оное, но вот когда нужно...

опять же лучше сначала думать о хорошем интерфейсе модуля

Я же написал, это первый этап

Сильно от задач зависит всё это

Кеп в студии Я хотел раньше написать это!

Ну так тред пошел о том что оптимизация не нужна

Пришлось надеть маску капитана

вообще надо смотреть насколько часто будет дёргаться библиотека

Ну так тред пошел о том что оптимизация не нужна

Я имел ввиду, что согласен с тобой)

А

Ну тогда ок

😄

И хотел скапитанить первее

тот же React например должен быть оптимизирован по самые яйца, так как он дёргается ПОСТОЯННО

А еще я уверен, что если Ельцин задумался о производительности, то зазря он это не сделает

и опять же, лучше даже оптимизировать по памяти, чем по быстродействию

по крайней мере для фронтенда

как мне кажется

тот же React например должен быть оптимизирован по самые яйца, так как он дёргается ПОСТОЯННО

А теперь посмотри какие результаты у модуля compose из redux

Вот в этом вся и фигня

как мне кажется

Такие разговоры обычно за рюмочкой или бокальчиком вести надо)

React != Redux

СПАСИБО БРО

Такие разговоры обычно за рюмочкой или бокальчиком вести надо)

так почти Новый год уже

так почти Новый год уже

Еще не свыкся с этой мыслью Надо шторы раздвинуть

Сап, дай ссылку на свой репо

Сап, дай ссылку на свой репо

Вот и я бы посмотрел

Я пока локально пишу, ща выложу тогда

Модуль — ensue@beta

давай

На идею меня натолкнула строка из тайпнгов ramda, ну где у них там на каждое число переданных функций свой pipeN

То есть можно развернуть все эти вычисления по switch/case и тем самым сэкономить значительное число вычислений

const pipe3 = (f1, f2, f3) => (...args) => f1(f2(f3(...args)));

можно быстрее написать?

Ага

const pipe3 = (f1, f2, f3) => (...args) => f1(f2(f3(...args)));

Смысл тот же, да, просто у них это объективно не очень оптимально

мне кажется быстрее нельзя

вангую у них перф проседает из-за аргументов

Да

а кроме этого, ещё где-то?

Во вложенном вызове функций

У них pipe вызывает _arity, reduce и tail, а те дёргают следующие функции

Если писат такие низкоуровневые вещи, то желательно без таких вызовов обходиться

мы так и до кодогенерации скоро дойдем 😂

Ну уже близко, да 😄

Кстати хорошая мысль

А если на ноде то можно и нативные модули