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

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

В моем видео есть пример кода, не просто пример кода, а в том числе его интепретируемая часть и в том числе машинный код. Который наглядно показывает когда как и как собирается код под reduce или под for.

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

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

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

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

arr.reduce( (p,e) => p+e);

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

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

Такие задачки решают детки 10 лет на кружке программирования.

Еще раз подчеркиваю.
Цель того что я говорю не дескредитировать чью либо компетенцию, но наглядно показать, как большая часть программистов не знают JavaScript и  при этом успешно на нем программируют.

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

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

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

Ну прям неопалимый разрушитель оков пришел в залив работорговцев :). Со многим согласен, может даже и со всем.

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

arr.reduce( (p,e) => p+e);
1) замыкание вижу.
2) а что значит заинлайнить?
3) вывод о чистоте функции сложно сделать что-то

А вообще эти три поста - это огонь

Ого вот это пальнул с утреца мат частью =))

«Оптимизации производительности это почти 85% рынка»
Хіба?

v8 - 85% ринку

хмм

Ага, сюда нельзя скрины заливать, кайф)

В общем у меня в хроме и в ноде (что логично), var вёл себя быстрее let и const

Потом пошёл тестить в мозилле, а там мало того, что var медленнее, так и по сравнению с хромом let/const проигрывали по скорости в 20 раз, а var в 50 🤪

ну вот гораздо же быстрее будет, чем ваш этот json

  std::map<std::string, std::vector<Product>> purchase {
    { "Electronics", {
      { "Laptop", 1500 },
      { "Keyboard", 100 },
      { "HDMI cable", 10 },
    } },
    { "Textile", {
      { "Bag", 50 },
    } },
  };

Ахах

Производительность переоценена 😐

Ну все, буду писати cryptic code, а коли мої колеги не зможуть його прочитати і зарев'ювити нормально — казатиму, що вони некваліфіковані спеціалісти

Не буду вникати в потреби бізнесу, натомість ковирятимусь в кишках V8

І оптимізовуватиму змінні

От тоді заживемо, так

я делал тесты по reduce, беря за базис ту логику что описана у Вас в видео, но менял только числа и фор быстрее. Если же почитать спеку, как работает редюс, то там по более инструкций будет, чем у for с примеров. Пример с оптимизациями на уровне let и var звучит забавно. Я так же знаю спецов которые получают огромные деньги, без таких специфических знаний поднаготной. То, что читабельность - это субьективная вещь, конечно же правада, но доказывает ли это что она не важна? Если бы Вы были в этом правы, то никто бы никогда не ушел бы от ассемблера и мы бы никогда не стремились бы писать высокоуровневые абстракции стараясь максимально не зависить от железа. Ведь в этом смысл выскоуровневых яп с GC - что бы создать такой мир, в котором не надо упарываться в понимании как там всё работает под капотом - для этого есть другие инструменты.

Та и батхёртить по поводу того, что "ктото говорит что var устарел" - нелепо. Многие им не пользуются, конечно же он никогда не будет deprecated - но тот факт, что сообщество  стараются его избегать по объективным причинам, как раз и делает его устаревшим