https://github.com/vanesyan/adventofcode2020/blob/master/src/15.js

Я конечно понимаю, что Array.push типо O(1), но реалокацию памяти, особенно когда 10^8 элементов никто не отменял

Я конечно понимаю, что Array.push типо O(1), но реалокацию памяти, особенно когда 10^8 элементов никто не отменял

Там массив попеременно 1 и 0 элементов имеет. Думаю движок не занимается реаллокацией, а просто меняет чиселку length и сохраняет число в первый слот массива

так с мапой он за 5сек решается, bottleneck в объекте был, который выдавал 3мин

Какой bottleneck?

поиск по объекту по ключу намного медленее, чем поиск по мапе

Какой bottleneck?

Разве на много?

я не замерял, но смена структуры дала снижение с 3мин до 5сек

map.has(n) быстрее n in obj или obj[n]. Потому что не ходит вверх по прототипу

map.has(n) быстрее n in obj или obj[n]. Потому что не ходит вверх по прототипу

К тому же целочисленных ключей, что заставляет объект их сортировать, ибо целочисленные неотрицательные ключи в объекте всегда отсортированы

К тому же целочисленных ключей, что заставляет объект их сортировать, ибо целочисленные неотрицательные ключи в объекте всегда отсортированы

Интересно проверить что будет если использовать ключи вида a123, что б они были не numeric

Зачем? Для быстрого поиска по ним в будущем?

Стандарт заставляет ибо некоторые разработчики рассчитывают на такое поведение несмотря на заявленную несортированность. Из-за них это протащили в стандарт

Где (where) правда?

Интересно проверить что будет если использовать ключи вида a123, что б они были не numeric

Ну да, это было особенностью имплементации. Но тут же как обычно, в (условном) browser1 так сделали. Разработчики browser2 и browser3 может и хотели бы по другому, но тогда ломались сайты тех авторов которые заложились на поведение browser1. Пришлось сделать так же. А потом глядь, и все считают что именно так и должно быть. Пришлось запихать в стандарт.

Лишь бы они были разумными)

вот такой роскоши может не быть 🙂

Ну и правильно, ручками тоже иногда надо работать

Когда оценивают конечный результат, а не код, то почему бы и нет?:)

Вопрос на засыпку (боюсь @alexeyten даже знает ответ): Что быстрее: arr1 = arr1.concat(arr2); или arr1.push(...arr2); ЕСЛИ ДЛИНА РАВНА: 1) 1_000_000 2) 100_000 3) 10_000

Вопрос на засыпку (боюсь @alexeyten даже знает ответ): Что быстрее: arr1 = arr1.concat(arr2); или arr1.push(...arr2); ЕСЛИ ДЛИНА РАВНА: 1) 1_000_000 2) 100_000 3) 10_000

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

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

Так если в хроме дебажить, то сам предлагает (...args) ввести несколько

Я просто сейчас понял, что никогда массово не добавлял ничего через пуш, поэтому видимо и не знал

И правильно делал. Хотя до 50 элементов можно

Спросили бы про ..., про то, как соединить 2 массива, но не про это

так речь как раз про ... , хотя и это я считаю не стоит спрашивать на собеседовании

Всм? Про спред операторы и ES6 всегда на скриниге спрашивают

если ты этого не знаешь, вряд ли это означает, что ты «плохой программист»

Так я это и сказал

Там подвох. Там будет 3 варианта: push совсем немного быстрее concat concat нормально так быстрее push Подвох, хоть и ожидаемый

так что же там начинает тормозить в ... после 50 элементов?

При 1000+ элементах concat быстрее При 1_000_000 Array.prototype.push(…) вылетает с ошибкой stackoverflow

прикол! 🔥 зачем-то рекурсивно пушит

Не рекурсией. Просто слишком большой call stack

а что такое call stack по смыслу? 😉

Ну, типо мы выгружаем слишком большое кол-во аргументов за раз