00:00:00 Работа программистов 00:00:57 Ограничения в программировании 00:02:07 Сообщество программистов 00:04:09 Красота кода 00:07:20 Паттерны и JavaScript 00:10:40 Баланс между производительностью и читаемостью 00:12:30 Комментарии и метаданные 00:13:19 Lisp и программирование 00:15:09 Интерпретатор и классы 00:16:05 Коллекция операторов 00:17:00 Абстрактный экспресс 00:18:50 Оптимизация и тестирование 00:22:45 Паттерны и классы 00:25:07 Приватные поля и наследование 00:28:22 Интерпретатор и компилятор 00:30:23 Испытание возможностей 00:31:22 Пример липового выражения 00:32:47 Производительность и оптимизация 00:33:42 Консты, вары и лэты 00:35:43 Модульность и замыкания 00:39:09 Оптимизация и производительность 00:42:52 Циклы и производительность 00:45:28 Обращение к свойствам объекта 00:46:23 Производительность и выражения 00:49:15 Использование сета 00:51:07 Оптимизация кода 00:54:36 Производительность и архитектура 00:56:53 Использование структур данных 00:59:04 Искусственный интеллект 01:01:06 Проблемы с использованием ИИ 01:04:28 Влияние ИИ на программирование 01:07:27 Дискуссия о компетенции 01:10:13 Вопросы и ответы 01:12:09 Эффективность структур данных 01:14:24 Внешние API и производительность 01:17:33 Оптимизация кода 01:27:50 Использование регулярных выражений 01:31:49 Преимущества и недостатки регулярных выражений 01:35:24 Заключение 01:36:08 Оптимизация парсинга 01:37:57 История о хакерах и солонках 01:40:08 Работа с токенами и слайсами 01:42:11 Тернарный оператор и оптимизация 01:45:36 Расширение библиотеки и функциональное программирование 01:48:13 Автоматы и стейт 01:50:47 Оптимизация кода с использованием дополнительных полей 01:51:47 Использование тайпов и инстансов 01:53:42 Метапрограммирование и создание собственного синтаксиса 01:55:14 Проверка наличия ключа в объекте 01:56:58 Использование юнион-тайпов в TypeScript 01:57:57 Проблемы с динамической подгрузкой модулей 01:59:17 Проблемы с использованием union types 02:00:46 Преимущества и недостатки TypeScript 02:02:54 Конечные автоматы и их реализация 02:06:14 Оптимизация кода и использование console.log 02:09:02 Объединение кода в классы 02:10:20 Введение в рей литерал парсер 02:11:18 Проблемы и улучшения парсера 02:12:15 Отделение рей литерал парсера от стейт машины 02:13:55 Применение стейт машины для других типов парсеров 02:15:33 Пример с азбукой Морзе 02:17:15 Использование строк в JavaScript 02:21:04 Создание и уничтожение объектов 02:23:16 Введение в State Machine 02:24:05 Преимущества State Machine 02:25:02 Реализация парсера на State Machine 02:26:28 Развитие кода и структура данных 02:28:42 Метапрограммирование и рефлексия 02:29:56 Полиморфизм и интерфейсы 02:31:01 Анекдоты и юмор 02:32:50 Паттерн State 02:34:41 Проблемы с копированием кода 02:36:33 Паттерн State 02:38:29 Пример реализации State Machine 02:42:47 Оптимизация и производительность 02:45:42 Пример с классом OrderState 02:48:01 Оптимизация геттеров и сеттеров 02:49:01 Оптимизация структур данных 02:50:49 Вложенные структуры и паттерны 02:52:31 Простота и наглядность 02:53:09 Оптимизация и наследование 02:55:33 Паттерны и их реализация 02:57:12 Практическое применение паттернов 02:59:48 Примеры из реальной жизни 03:01:15 Заключение и благодарности 03:02:47 Проблемы в программировании 03:03:40 Оптимизация и производительность 03:04:35 Упрощение кода 03:06:15 Оптимизация в Node.js 03:07:39 Альтернативные решения 03:09:40 Вопросы и завершение
Комментарий к первым 5 минутам видео. Если мне приходится делать задачу, которую я 10 раз делал, то пытаюсь сделать по другому/лучше (может быть идея как сделать или сделаю какой-то investigation на тему, как сделать по иному). Стараюсь час рабочего времени посвящать чтению книг, а потом думать, как применить в коде полученные знания. К сожалению, много проектов, где на тебя закидывают кучу форм/сервисов и ты не поднимая головы клепаешь их, потому что надо успеть. В таком режиме, проходят годы, но роста умений не наблюдается, потому что дьявол водит тебя по кругу.
1:28:00 Кстати о template strings. Случайно обнаружил что выражение `${[1, 2]}` превращается в строчку '1,2', т.е как будто происходит [1, 2].split(','). Удобный способ превратить массив в строку в моём случае, но я не нашёл этому объяснения. Кто-нибудь сталкивался?
There isn't the Array.prototype.split method. To convert an array to a string, use the Array.prototype.join method instead. const arr = [1, 2]; const string = arr.join(','); console.log(string === `${arr}`); // true console.log(string === arr.toString()); // true
Какие-то странные зрители. Выключил, потому что жопа сгорела от глупости. Как минимум, если хочешь задать вопрос, сформулируй его заранее и задай, а не мычи полчаса в микрофон. Столько воды говорят, чтобы показаться умными.
"Не самый производительный алгоритм а самый красивый" - напомнило шутку Галыгина о итальянском танке Нино Ричи - не едет, не стреляет, но очень красивый
10:43 почему же тогда Мурыч так гнобил Соера? Тот как раз ссылался на то, что у него все отлично работает, а Мурыч его доставал тем, что тот якобы действовал не строго согласно документации.
Где нужно я и накричать могу, когда-то в МВД пришел в отдел кадров с мухобойкой, орал и шлепал по столу, пока мне сотню трудовых книжек не отдали в руки, а тети из бухгалтерии смотрели через щелку в приоткрытую дверь и шептались - смотри как кричит, точно генералом будет, аш страшно...
Я в принципе всегда мог позволить себе не работать за деньги, продавать свой труд это как-то не эффективно много не заработаешь... Деньги гораздо лучше отжать, а ещё лучше, когда клиенты сами принесут, приползут на коленях с дарами...
54:07 - "switch-case синтаксический сахар на if-else" - "Дед" это так уверенно сказал, что я чуть было даже не поверил. Но остаток здравомыслия заставил меня это проверить. Естественно это не так ни в V8 ни SpiderMonkey ни даже в Rhino. Я боюсь себе представить сколько еще было сказано откровенной неправды с уверенным лицом за эти 3 часа видео.
@@TimurShemsedinovну в Си свитч действительно работает лучше, чем аналогичная конструкция с if-else, так что предположение что в джс будет так же вполне обосновано
Вы посмотрите батенька в байт код. И потом несите свет в массы. Код идентичен. И Вам бы следовало показать КАК Вы это проверили. Я это смотрб на уровне генерируемого байткода V8 и на уровне выдаваемых оптимизаций TurboFan, а Вы каким образом?
@@Мартынов-х3ъ Совершенно верно. Дело в том, что любая конструкция языка - это абстракция которая может определять поле возможных оптимизаций конкретно для нее. Когда оптимизирующий алгоритм выделяет часть кода, который обьеденен общим синтаксисом - он может делать определенные выводы относительно того, что с этим можно сделать более эффективно. JS не исключение. И я говорил в этом видео, что для switch case в V8 есть целый ряд своих исключительных оптимизаций. Но если брать ОБЩИЙ случай - то это генерирует код идентичный коду с if else.
@@TimurShemsedinov @demimurych1 Сейчас я вам обосную, что switch-case и цепочка if-else-if это не одно и тоже и не является синтаксическим сахаром. Начнём с того что мы заглянем в исходники v8 /src/ast/ast_h там мы сможем найти SwitchStatement и IfStatement, первый отвечает за конструкцию switch и наследует BreakableStatement, второй - соответственно if и он просто Statement. BreakableStatement это всё, что умеет делать break на метку, switch это естественно умеет(но мало кто про это знает) console.log("1"); label: { console.log("2"); switch (1) { case 1: break label; } console.log("3"); } // 1, 2 По мимо всего этого case блок не имеет области изоляции для let, const, (ну это не аргумент естественно, просто хотелось бы представить как это сэмулировать такое в if-else-if? кинуть ошибку (has already been declared) прямо в коде ?:) а как собрать трейс этой ошибки ?) Поехали дальше и проследим за судьбой SwitchStatement. в коде он будет фигурировать под опкодом IrOpcode::kSwitch IfStatement же с большой вероятностью будет IrOpcode::kBranch - то что должно иметь then и else блоки (v8 добавит else если он отсутствует) Некоторые эвристики по оптимизациям будут с ними работать как с одним и тем же Вот например /src/compiler/dead-code-elimination_cc (строка 70) но есть и случаи когда будут разные подходы src/compiler/simplified-lowering_cc (2451) Дальше мне придется поверить на слово, так как в коде это очень сложно показать. Для switch-case есть достаточно много оптимизаций уже на уровне turbofan, вот некоторые из них: 1) это, как ни странно, деградация до if-else (cmp, je) 2) jump-table - если case содержит что-то что монотонно, нумерабельно и с минимальным кол-вом "дырок" 3) hash-table - если case блоков достаточно много и они уже не монотонно нумеруются В эти же эвристики может угодить и что-то branch подобное типа if-else но на деле не так быстро и не всегда как switch-case А теперь самое интересное и по большей степени бесполезное: эксперимент на кошках Берем примитивный пример switch(number)-case-break для 10 элементов и пишем аналогичный if-else-if и проверяем через node --print-bytecode в итоге, на sitch-case мы увидем SwitchOnSmiNoFeedback или что-то подобное, а на if-else-if мы увидим просто 10 TestEqual ... То что эти конструкции разные надеюсь вам стало понятно. Теперь остаётся один нюанс - понять что такое синтаксический сахар. если имеется ввиду то, что компилятор всегда разварачивает swith в if-else-if - это не правда если имеется ввиду то, что упрощает код - то тогда про всё можно сказать, что это сахар. вот тот же if - это же сахар над je, jne, jz
О какой оптимизации JS рассуждения? Тут билд тулзы пишут уже на чём угодно (esbuild - go, swc - rust, farm - rust, oxc - rust) но не на JS, потому что никакая серьёзная оптимизация на нём невозможна. Потому что оптимизация тем лучше, тем детальнее ты можешь объяснить что конкретно будет делать конечная железка, на котором твоя программа будет исполняться. В оптимизированном же JS невозможно ничего. Ни точно знать когда будет деаалокация/аллокация памяти, ни какой размер будет структуры данных, ни какую примерно последовательность инструкций будет выполнять процессор. (Дадада с современным компилятором предсказывать подобное тоже практически невозможно, но условный С++ ты можешь собрать и посмотреть какую последовательность инструкций оно там тебе нагенерировало). В итоге всё приходит к алгоритмической оптимизации (когда явно один алгоритм быстрее), потому что ускорить тот же самый алгоритм в JS получится лишь уга-уга экспериментами. Ибо контроля над тем, что процессор будет делать - никакого нет. Оптимизация JS это адовый костыль поверх самой неправильной идеи JS.
Байт-код который генерирует V8 конечно может отличаться от версии к версии, но общие принципы оптимизации прекрасно усваиваются, если немного знать ассемблер и освоить тулинг. Если писать мономорфный код, не делать примесей, не менять типы на лету, понимать, как работает инлайнинг и формы объектов, то можно писать код лишь немного медленнее C++. Вот Prisma переписали с Rust на TypeScript www.prisma.io/blog/prisma-orm-manifesto А в ноде llparser сделан на TypeScript и компилируется в C и потом уже плагин для ноды. Так что, есть разные варианты, кроме прямого исполнения на V8, и о общем случае, JS может порвать многие так называемые компилируемые языки
@@MrKatunins Правильно, лучше не смотреть, иначе могут быть сложности на работе и вообще с кодом становится сложно работать, все так таинственно и неоднозначно. Если человек эффективен, то ему необязательно знать, как все на самом деле, меньше знаешь, лучше спишь
Вообще, если человек умеет пользоваться тулингом для дебага и декомпиляции, то js можно довести до скорости C++, а таких товарищей, как Java и C# вообще можно взуть по скорости, не всегда, и не для любых задач, это не просто и не дёшево, но вот писать на уровне меинстрима компилируемых языков ±15% производительности вообще изи
00:00:00 Работа программистов
00:00:57 Ограничения в программировании
00:02:07 Сообщество программистов
00:04:09 Красота кода
00:07:20 Паттерны и JavaScript
00:10:40 Баланс между производительностью и читаемостью
00:12:30 Комментарии и метаданные
00:13:19 Lisp и программирование
00:15:09 Интерпретатор и классы
00:16:05 Коллекция операторов
00:17:00 Абстрактный экспресс
00:18:50 Оптимизация и тестирование
00:22:45 Паттерны и классы
00:25:07 Приватные поля и наследование
00:28:22 Интерпретатор и компилятор
00:30:23 Испытание возможностей
00:31:22 Пример липового выражения
00:32:47 Производительность и оптимизация
00:33:42 Консты, вары и лэты
00:35:43 Модульность и замыкания
00:39:09 Оптимизация и производительность
00:42:52 Циклы и производительность
00:45:28 Обращение к свойствам объекта
00:46:23 Производительность и выражения
00:49:15 Использование сета
00:51:07 Оптимизация кода
00:54:36 Производительность и архитектура
00:56:53 Использование структур данных
00:59:04 Искусственный интеллект
01:01:06 Проблемы с использованием ИИ
01:04:28 Влияние ИИ на программирование
01:07:27 Дискуссия о компетенции
01:10:13 Вопросы и ответы
01:12:09 Эффективность структур данных
01:14:24 Внешние API и производительность
01:17:33 Оптимизация кода
01:27:50 Использование регулярных выражений
01:31:49 Преимущества и недостатки регулярных выражений
01:35:24 Заключение
01:36:08 Оптимизация парсинга
01:37:57 История о хакерах и солонках
01:40:08 Работа с токенами и слайсами
01:42:11 Тернарный оператор и оптимизация
01:45:36 Расширение библиотеки и функциональное программирование
01:48:13 Автоматы и стейт
01:50:47 Оптимизация кода с использованием дополнительных полей
01:51:47 Использование тайпов и инстансов
01:53:42 Метапрограммирование и создание собственного синтаксиса
01:55:14 Проверка наличия ключа в объекте
01:56:58 Использование юнион-тайпов в TypeScript
01:57:57 Проблемы с динамической подгрузкой модулей
01:59:17 Проблемы с использованием union types
02:00:46 Преимущества и недостатки TypeScript
02:02:54 Конечные автоматы и их реализация
02:06:14 Оптимизация кода и использование console.log
02:09:02 Объединение кода в классы
02:10:20 Введение в рей литерал парсер
02:11:18 Проблемы и улучшения парсера
02:12:15 Отделение рей литерал парсера от стейт машины
02:13:55 Применение стейт машины для других типов парсеров
02:15:33 Пример с азбукой Морзе
02:17:15 Использование строк в JavaScript
02:21:04 Создание и уничтожение объектов
02:23:16 Введение в State Machine
02:24:05 Преимущества State Machine
02:25:02 Реализация парсера на State Machine
02:26:28 Развитие кода и структура данных
02:28:42 Метапрограммирование и рефлексия
02:29:56 Полиморфизм и интерфейсы
02:31:01 Анекдоты и юмор
02:32:50 Паттерн State
02:34:41 Проблемы с копированием кода
02:36:33 Паттерн State
02:38:29 Пример реализации State Machine
02:42:47 Оптимизация и производительность
02:45:42 Пример с классом OrderState
02:48:01 Оптимизация геттеров и сеттеров
02:49:01 Оптимизация структур данных
02:50:49 Вложенные структуры и паттерны
02:52:31 Простота и наглядность
02:53:09 Оптимизация и наследование
02:55:33 Паттерны и их реализация
02:57:12 Практическое применение паттернов
02:59:48 Примеры из реальной жизни
03:01:15 Заключение и благодарности
03:02:47 Проблемы в программировании
03:03:40 Оптимизация и производительность
03:04:35 Упрощение кода
03:06:15 Оптимизация в Node.js
03:07:39 Альтернативные решения
03:09:40 Вопросы и завершение
Единственное, что я понял, это то, что вместо просмотра этих видео, мне следует вернуться к учёбе.
Согласен, из того что я понял. Я ничего не понимаю…
Have you already worked as a professional programmer? How long?
@@OleksiiMalichenko Have you already worked as a professional programmer?. How long?
@@yaroslavbox1249 Have you already worked as a professional programmer?. How long?
@@kowkavn2356 No, I haven't yet. But I can understand a little what they're talking about. How about you?
Спасибо что не бросаете деда ❤
Комментарий к первым 5 минутам видео.
Если мне приходится делать задачу, которую я 10 раз делал, то пытаюсь сделать по другому/лучше (может быть идея как сделать или сделаю какой-то investigation на тему, как сделать по иному).
Стараюсь час рабочего времени посвящать чтению книг, а потом думать, как применить в коде полученные знания.
К сожалению, много проектов, где на тебя закидывают кучу форм/сервисов и ты не поднимая головы клепаешь их, потому что надо успеть. В таком режиме, проходят годы, но роста умений не наблюдается, потому что дьявол водит тебя по кругу.
Нужно уметь отказывать. Опыт показывает, что отказы воспринимаются нормально
Отличный и познавательный выпуск для меня. Я благодарен вам.
Отдельная уважуха коллегам за крупный шрифт на экране!
Дякую за змістовний зворотній звязок, і цікаве відео)
база база база, спасибо за колаб 🥰
Конечно, не то что твои видео)
Спасибо. Буду слушать под Рождество под ёлочкой.
00:59:00 про ИИ вот прям в точку сказано! Мое уважение Мурычу.😁
1:28:00 Кстати о template strings. Случайно обнаружил что выражение `${[1, 2]}` превращается в строчку '1,2', т.е как будто происходит [1, 2].split(','). Удобный способ превратить массив в строку в моём случае, но я не нашёл этому объяснения. Кто-нибудь сталкивался?
@@silent-do вызывается .toString()
@@TimurShemsedinovБлагодарю
There isn't the Array.prototype.split method. To convert an array to a string, use the Array.prototype.join method instead.
const arr = [1, 2];
const string = arr.join(',');
console.log(string === `${arr}`); // true
console.log(string === arr.toString()); // true
Вот этого я ждал очень долго!!! Титаны мысли!
Спасибо всем причастным
Какие-то странные зрители. Выключил, потому что жопа сгорела от глупости. Как минимум, если хочешь задать вопрос, сформулируй его заранее и задай, а не мычи полчаса в микрофон. Столько воды говорят, чтобы показаться умными.
"Не самый производительный алгоритм а самый красивый" - напомнило шутку Галыгина о итальянском танке Нино Ричи - не едет, не стреляет, но очень красивый
@@frstnmlstnm-it1mf Questo e meraviglioso 🤌
10:43 почему же тогда Мурыч так гнобил Соера? Тот как раз ссылался на то, что у него все отлично работает, а Мурыч его доставал тем, что тот якобы действовал не строго согласно документации.
он больной в прямом и переносном смысле
гарна дискусія дуже така трохи душна))
@@boyywnkobe так і планувалося
Тимур почему вы такой спокойный?) и всегда общались спокойно, как так?) откройте секрет)
на седативных сидит возможно)
Потому что зарабатывает очень хорошо и в спокойном режиме в тч на консультациях. Не как дефолтный кодер😂
Пійте чай. Ось і весь секрет. ☕
Хороший чай -- запорука успіху
Где нужно я и накричать могу, когда-то в МВД пришел в отдел кадров с мухобойкой, орал и шлепал по столу, пока мне сотню трудовых книжек не отдали в руки, а тети из бухгалтерии смотрели через щелку в приоткрытую дверь и шептались - смотри как кричит, точно генералом будет, аш страшно...
4:38 - ради красоты можно что угодно делать, даже навалять красиво! главное ведь что? правильно, главное - ничего!
Ну ну, всё не ради денег) Дайте щас зп 500$ всем мидлам и сеньорам. Посмотрим как компании будут существовать) Тоже мне любители кода)
Я в принципе всегда мог позволить себе не работать за деньги, продавать свой труд это как-то не эффективно много не заработаешь... Деньги гораздо лучше отжать, а ещё лучше, когда клиенты сами принесут, приползут на коленях с дарами...
54:07 - "switch-case синтаксический сахар на if-else" - "Дед" это так уверенно сказал, что я чуть было даже не поверил. Но остаток здравомыслия заставил меня это проверить. Естественно это не так ни в V8 ни SpiderMonkey ни даже в Rhino. Я боюсь себе представить сколько еще было сказано откровенной неправды с уверенным лицом за эти 3 часа видео.
@@EgorFrade Научись пользоваться дезасемблером, у Мурыча на канале точно есть видео, где он показывает нужный тулинг, они генерируют идентичный код
@@TimurShemsedinovну в Си свитч действительно работает лучше, чем аналогичная конструкция с if-else, так что предположение что в джс будет так же вполне обосновано
Вы посмотрите батенька в байт код. И потом несите свет в массы.
Код идентичен.
И Вам бы следовало показать КАК Вы это проверили. Я это смотрб на уровне генерируемого байткода V8 и на уровне выдаваемых оптимизаций TurboFan, а Вы каким образом?
@@Мартынов-х3ъ Совершенно верно. Дело в том, что любая конструкция языка - это абстракция которая может определять поле возможных оптимизаций конкретно для нее.
Когда оптимизирующий алгоритм выделяет часть кода, который обьеденен общим синтаксисом - он может делать определенные выводы относительно того, что с этим можно сделать более эффективно.
JS не исключение. И я говорил в этом видео, что для switch case в V8 есть целый ряд своих исключительных оптимизаций.
Но если брать ОБЩИЙ случай - то это генерирует код идентичный коду с if else.
@@TimurShemsedinov @demimurych1
Сейчас я вам обосную, что switch-case и цепочка if-else-if это не одно и тоже и не является синтаксическим сахаром.
Начнём с того что мы заглянем в исходники v8 /src/ast/ast_h
там мы сможем найти SwitchStatement и IfStatement, первый отвечает за конструкцию switch и наследует BreakableStatement,
второй - соответственно if и он просто Statement.
BreakableStatement это всё, что умеет делать break на метку, switch это естественно умеет(но мало кто про это знает)
console.log("1");
label: {
console.log("2");
switch (1) {
case 1: break label;
}
console.log("3");
} // 1, 2
По мимо всего этого case блок не имеет области изоляции для let, const, (ну это не аргумент естественно, просто хотелось бы представить как это сэмулировать такое в if-else-if? кинуть ошибку (has already been declared) прямо в коде ?:) а как собрать трейс этой ошибки ?)
Поехали дальше и проследим за судьбой SwitchStatement. в коде он будет фигурировать под опкодом IrOpcode::kSwitch
IfStatement же с большой вероятностью будет IrOpcode::kBranch - то что должно иметь then и else блоки (v8 добавит else если он отсутствует)
Некоторые эвристики по оптимизациям будут с ними работать как с одним и тем же
Вот например /src/compiler/dead-code-elimination_cc (строка 70) но есть и случаи когда будут разные подходы src/compiler/simplified-lowering_cc (2451)
Дальше мне придется поверить на слово, так как в коде это очень сложно показать.
Для switch-case есть достаточно много оптимизаций уже на уровне turbofan, вот некоторые из них:
1) это, как ни странно, деградация до if-else (cmp, je)
2) jump-table - если case содержит что-то что монотонно, нумерабельно и с минимальным кол-вом "дырок"
3) hash-table - если case блоков достаточно много и они уже не монотонно нумеруются
В эти же эвристики может угодить и что-то branch подобное типа if-else но на деле не так быстро и не всегда как switch-case
А теперь самое интересное и по большей степени бесполезное: эксперимент на кошках
Берем примитивный пример switch(number)-case-break для 10 элементов и пишем аналогичный if-else-if и проверяем через node --print-bytecode
в итоге, на sitch-case мы увидем SwitchOnSmiNoFeedback или что-то подобное, а на if-else-if мы увидим просто 10 TestEqual ...
То что эти конструкции разные надеюсь вам стало понятно. Теперь остаётся один нюанс - понять что такое синтаксический сахар.
если имеется ввиду то, что компилятор всегда разварачивает swith в if-else-if - это не правда
если имеется ввиду то, что упрощает код - то тогда про всё можно сказать, что это сахар. вот тот же if - это же сахар над je, jne, jz
Не правда 3:42. самые большие мазохисты это врачи
Лайк, підтримка, коментар
конфа 👍
О какой оптимизации JS рассуждения? Тут билд тулзы пишут уже на чём угодно (esbuild - go, swc - rust, farm - rust, oxc - rust) но не на JS, потому что никакая серьёзная оптимизация на нём невозможна. Потому что оптимизация тем лучше, тем детальнее ты можешь объяснить что конкретно будет делать конечная железка, на котором твоя программа будет исполняться.
В оптимизированном же JS невозможно ничего. Ни точно знать когда будет деаалокация/аллокация памяти, ни какой размер будет структуры данных, ни какую примерно последовательность инструкций будет выполнять процессор. (Дадада с современным компилятором предсказывать подобное тоже практически невозможно, но условный С++ ты можешь собрать и посмотреть какую последовательность инструкций оно там тебе нагенерировало). В итоге всё приходит к алгоритмической оптимизации (когда явно один алгоритм быстрее), потому что ускорить тот же самый алгоритм в JS получится лишь уга-уга экспериментами. Ибо контроля над тем, что процессор будет делать - никакого нет.
Оптимизация JS это адовый костыль поверх самой неправильной идеи JS.
Байт-код который генерирует V8 конечно может отличаться от версии к версии, но общие принципы оптимизации прекрасно усваиваются, если немного знать ассемблер и освоить тулинг. Если писать мономорфный код, не делать примесей, не менять типы на лету, понимать, как работает инлайнинг и формы объектов, то можно писать код лишь немного медленнее C++. Вот Prisma переписали с Rust на TypeScript www.prisma.io/blog/prisma-orm-manifesto А в ноде llparser сделан на TypeScript и компилируется в C и потом уже плагин для ноды. Так что, есть разные варианты, кроме прямого исполнения на V8, и о общем случае, JS может порвать многие так называемые компилируемые языки
Как можно красиво побороться с двумя вложенными if'ами ?
Смотря какими, но вложенные if это не так плохо, тут только читаемость можно повысить, сделав промежуточные идентификаторы
Вот это коллаб)
6:02
УФ УФ УФ! ЗАВЕЗ!
❤
Не стал смотреть
@@MrKatunins Правильно, лучше не смотреть, иначе могут быть сложности на работе и вообще с кодом становится сложно работать, все так таинственно и неоднозначно. Если человек эффективен, то ему необязательно знать, как все на самом деле, меньше знаешь, лучше спишь
@@MrKatunins тут у меня несколько людей с курса пишут, что не могут теперь работать и смотреть ни на код коллег ни на свой
@@TimurShemsedinov Не, просто то что вы показываете, на практике не используется никогда
@@Edgar-pu1lcчто именно и на кокой практике?
правильно, ценность чуть выше чем 0
Оптимизация ДжаваСкрипт? Ха-ха-ха.
Вообще, если человек умеет пользоваться тулингом для дебага и декомпиляции, то js можно довести до скорости C++, а таких товарищей, как Java и C# вообще можно взуть по скорости, не всегда, и не для любых задач, это не просто и не дёшево, но вот писать на уровне меинстрима компилируемых языков ±15% производительности вообще изи