Будет ли результат в Object.assign в режиме словаря, если я использую объекты в медленном режиме?
Если вы используете платформу тестирования, например Mocha , с библиотекой утверждений Chai , вы можете использовать равенство deep для сравнения массивов.
expect(a1).to.deep.equal(a2)
Это должно возвращать true, только если массивы имеют равные элементы в соответствующих индексах.
1 ответ
(здесь разработчик V8.) Краткий ответ: в этом примере bar обладает «быстрыми» свойствами.
Вы можете убедиться в этом сами, запустив d8 (или узел) с флагом --allow-natives-syntax, а затем воспользовавшись специальной функцией %HasFastProperties(bar).
Тем не менее, это внутренняя деталь реализации, которая может со временем измениться. Это не должно быть то, что ваш код должен иметь причины для заботы.
В частности, я не знаю, поэтому ли вы спрашиваете об этом, поэтому я просто хотел бы сказать превентивно, что я настоятельно рекомендую против создать любой пользовательский «форсированный быстрый режим» помощники, которые копируют объекты - по всей вероятности, это сожжет больше времени и памяти, чем экономит, и может внезапно прекратить делать то, что, как вы думаете, делает, даже без вашего ведома.
Более общая картина здесь заключается в том, что «быстрые свойства» и «медленные свойства» являются неправильными. Лучшими терминами были бы «свойства для быстрого чтения» и «свойства для быстрого изменения»: причина, по которой оператор delete (обычно) переводит объект в режим словаря, заключается в том, что добавление и удаление свойств очень много быстрее , когда объект находится в режиме словаря, чем когда он находится в (плохо названном) «режиме быстрого свойства». В большинстве случаев эвристика V8 делает довольно хорошую работу по выбору правильного внутреннего режима для ваших объектов, и вы обычно можете сосредоточиться на написании чистого кода, а не беспокоиться о внутренностях движка.
(Если бы это было так же просто, как иметь «хороший случай» и «плохой случай», то V8 было бы глупо иметь «плохой случай» вообще, и вы бы хотели флаг --always-good-case ( или просто --dont-be-silly), верно? ;-) Реальность такова, что это компромисс: «хорошо для одного» против «хорошо для другого».)