N
если я напишу
let f = x => x * 42;
что может сделать такого компилятор что функция перестанет быть чистой?
let f = x => x * 42;
что может сделать такого компилятор что функция перестанет быть чистой?
Size: a a a
2021 November 15
S
S
import { performance } from "perf_hooks";
const numbers = [];
for (let i = 0; i < 100_000_000; i++) {
numbers.push(i);
}
function sum(numbers) {
return numbers.reduce((acc, curr) => acc + curr, 0);
}
let startPerf = performance.now();
const result = sum(numbers);
let endPerf = performance.now();
console.log(result, endPerf - startPerf);EK
не понял вопроса
N
что такого сделать может компилятор с моей функцией?
N
зачем ему это знать?
EK
я ничего не знаю что компилятор может с неё сделать
EK
в таких тривиальных примерах нет сайд эффектов
EK
но мы говорим что есть замыкания, что могут быть мутации обьектов внутри функций
EK
а версия с фор?
S
import { performance } from "perf_hooks";
const numbers = [];
for (let i = 0; i < 100_000_000; i++) {
numbers.push(i);
}
function sum(numbers) {
let result = 0;
for (let i = 0; i < numbers.length; i++) {
result += numbers[i];
}
return result;
}
let startPerf = performance.now();
const result = sum(numbers);
let endPerf = performance.now();
console.log(result, endPerf - startPerf);EK
я чуть по другому писал тест с for и reduce, ближе к тому как делал автор и в итоге reduce был медленее всего на 20%
S
Я якось пропустив той момент. Написав чисто з голови.
M
По-моєму Фаулер говорив, що код в першу чергу портрібно писати так, щоб він легко читався і підтримувався. Тоді, якщо навіть виявиться що він не достатньо performant, його лекше буде відрефакторити.
Якщо підходити з цієї позиції, for не такий читабельний як reduce. for of і for in доволі читабельні.
Рекурсія часто — найбільш читабельна серед іншого.
Тому я часто беру її, навіть якщо знаю що вона не настільки performant.
Оптимізація — це рефакторинг, не потрібно про неї так аж сильно думати на етапі написання коду
Якщо підходити з цієї позиції, for не такий читабельний як reduce. for of і for in доволі читабельні.
Рекурсія часто — найбільш читабельна серед іншого.
Тому я часто беру її, навіть якщо знаю що вона не настільки performant.
Оптимізація — це рефакторинг, не потрібно про неї так аж сильно думати на етапі написання коду
S
на роботі я завжди за код-стайл і forEach/map/etc.
Д
там еще надо учитывать тот факт что пока v8 гоняет редьюс, он может пытаться подобрать оптимальные алгоритмы тем замедляя работу
Д
а фор он наврядли даже попытается оптимизировать
EK
я тоже больше предпочитаю reduce, map, forEach так как они явно показывают что должно произойти но мне сложно представить как компилятор в контексте js возьмет и поймет что всё "чисто" и можно делать агрессивные оптимизации
2021 November 16
DM
Позвольте мне кое что Вам пояснить.
О оптимизации производительности.
Все эти вещи действительно специфичны только для v8. Нужно ли ими заниматься в ситуации когда это почти 85% рынка вообще, и 93% embed рынка - судить вам.
Скажу только, что таких специалистов на рынке почти нет. И стоят они очень дорого. И стоят они дорого не потому, что они знают пару шаманских приемов которые дадут прирост в условные 10%. А потому, что написанный ими код, будет либо работать ровно так же в любом рантайме, либо быстрее если это целевой рантайм.
О коде, который должен быть прежде всего понятным.
Этот тезис имеет две очень интересные стороны.
То насколько код понятен, зависит в большей степени не от самого кода, а от прослойки между клавиатурой и стулом. Иными словами чем выше квалификация специалиста - тем более сложный код кажется ему простым.
Например любой специалист в реверс инжениринге, влет читает ассемблерный листинг. При этом читает этот код он не на уровне интерпретации команд, а целыми блоками. Мне достаточно взглянуть на листинг кода, чтобы не вникая в детали сказать что он делает и как он это делает. И так у любого специалиста с подобным навыком.
И вторая сторона. Тезис о понятности кода, возник в то время, когда рынок требовал большого количества программистов. Именно тогда появляются языки программирования типа Java или JavaScript как ответ на эту потребность. Потому что такие специалисты дешево стоят и их можно наплодить как кроликов. Главное привить им верные паттерны, первый из которых - когда ты не понимаешь что ты делаешь - то пиши понятный код.
Боже вас упаси думать, что я дискредетирую как одних так и других.
Более того, современный runtime стал предоставлять такие возможности, которые стали требовать дейтсвительно очень крепких специалистов, понимающих внутрь этого рантайма.
Просто посмотрите в код например яндекс карт, или в код Google Docs.
О оптимизации производительности.
Все эти вещи действительно специфичны только для v8. Нужно ли ими заниматься в ситуации когда это почти 85% рынка вообще, и 93% embed рынка - судить вам.
Скажу только, что таких специалистов на рынке почти нет. И стоят они очень дорого. И стоят они дорого не потому, что они знают пару шаманских приемов которые дадут прирост в условные 10%. А потому, что написанный ими код, будет либо работать ровно так же в любом рантайме, либо быстрее если это целевой рантайм.
О коде, который должен быть прежде всего понятным.
Этот тезис имеет две очень интересные стороны.
То насколько код понятен, зависит в большей степени не от самого кода, а от прослойки между клавиатурой и стулом. Иными словами чем выше квалификация специалиста - тем более сложный код кажется ему простым.
Например любой специалист в реверс инжениринге, влет читает ассемблерный листинг. При этом читает этот код он не на уровне интерпретации команд, а целыми блоками. Мне достаточно взглянуть на листинг кода, чтобы не вникая в детали сказать что он делает и как он это делает. И так у любого специалиста с подобным навыком.
И вторая сторона. Тезис о понятности кода, возник в то время, когда рынок требовал большого количества программистов. Именно тогда появляются языки программирования типа Java или JavaScript как ответ на эту потребность. Потому что такие специалисты дешево стоят и их можно наплодить как кроликов. Главное привить им верные паттерны, первый из которых - когда ты не понимаешь что ты делаешь - то пиши понятный код.
Боже вас упаси думать, что я дискредетирую как одних так и других.
Более того, современный runtime стал предоставлять такие возможности, которые стали требовать дейтсвительно очень крепких специалистов, понимающих внутрь этого рантайма.
Просто посмотрите в код например яндекс карт, или в код Google Docs.
DM
О var let и const
Все рассуждения о
По двум причинам:
1) об этом нет ни слова в толксах, или в специфификации.
2) var это лексическая конструкция которая обладает качествами иного характера чем
И против этого факта невозможно спорить по одной простой причине. Кодовая база ранйтайма для const и для let это кодовая база var с дополнительным блоком контроля области видимости. Исходники v8 открыты. Как и возможность сгенерировать дамп как байт кода так и машинного кода генерируемого turbofun. Что я и продемонстрировал в видео.
Который (дополнительный код контроля блочной области) отключается и не принимает никакого участия в работе, только в ситуациях, когда уровень вложенности блоков для заявленного идентификатора не больше одного. То есть интерпретатор может точно знать о рамках
Мои бенчмарки на эту тему, наглядно это демонстрируют как на уровне цифр - то есть можно создать такой код, когда использование
И все это призвано заявить три тезиса:
1)
2) если программист знает и четко отдает себе отчет в том как работает
Все рассуждения о
var let и const в первую очередь связаны с тем, чтобы продемонстрировать, что любые рассуждения о том? что дескать var устарел и настощие тру программисты используют только let и const, под собой не имеют никаких оснований. По двум причинам:
1) об этом нет ни слова в толксах, или в специфификации.
2) var это лексическая конструкция которая обладает качествами иного характера чем
let и const. Строго говоря, let и const это эквивалент var с дополнительной логикой обеспечения контроля блочной области видимости. И против этого факта невозможно спорить по одной простой причине. Кодовая база ранйтайма для const и для let это кодовая база var с дополнительным блоком контроля области видимости. Исходники v8 открыты. Как и возможность сгенерировать дамп как байт кода так и машинного кода генерируемого turbofun. Что я и продемонстрировал в видео.
Который (дополнительный код контроля блочной области) отключается и не принимает никакого участия в работе, только в ситуациях, когда уровень вложенности блоков для заявленного идентификатора не больше одного. То есть интерпретатор может точно знать о рамках
TDZ - temporal dead zone.
Из этого следует очень простой вывод - априори let и conts не могут заменить var в силу того что это тот же самый var с дополнительными издержками на обеспечения их работы.Мои бенчмарки на эту тему, наглядно это демонстрируют как на уровне цифр - то есть можно создать такой код, когда использование
let и const приведет к статистически фиксируемой разнице в производительности, в сравнении с тем же кодом но в котором использован var. И все это призвано заявить три тезиса:
1)
var не устарел и никогда не устареет, по причине того, что это ровно таже кодовая база что и let с const. Никто его из стандарта никогда не удалит. И это я еще не углублялся в пояснения работы GC, что только var ползволяет легко контролировать работу GC. В отличии от let с const которые в силу их особенностей работы, создают условия когда осуществить такой контроль не представляется возможным в принципе.2) если программист знает и четко отдает себе отчет в том как работает
var, ему let и const не нужны, потому как они не дают ему ровно никаких преимуществ в работе. За исключением специфических случаев эксплуатации оптимизаций для const на уровне turbofun.