this.key vs variable performace

Question

Стоит ли хранить значения this.key в переменных?

Может ли это повлиять на скорость при допущении, что я должен выполнять эту операцию в каждом кадре?

Простой пример:

class Vector3 { 
    constructor(X = 0, Y = 0, Z = 0) { 
     this.X = X 
     this.Y = Y 
     this.Z = Z 
    } 
    toVector2() { 
     return new Vector2(
      (this.Y - this.X) * COS27, 
      -((this.Y + this.X) * SIN27 + this.Z) 
     ) 
    } 
} 

против

class Vector3 { 
    constructor(X = 0, Y = 0, Z = 0) { 
     this.X = X 
     this.Y = Y 
     this.Z = Z 
    } 
    toVector2() { 
     const {X, Y, Z} = this 
     return new Vector2(
      (Y - X) * COS27, 
      -((Y + X) * SIN27 + Z) 
     ) 
    } 
} 

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

Answer 1

Другие ответы в корне неверны, поскольку они игнорируют оптимизацию, выполняемую двигателем. Современные двигатели обычно будут кэшировать this.X, если это необходимо, чтобы дальнейший доступ не включал поиск. Даже возможно, что двигатель мог бы выполнить работу с кешированием, чем вы могли бы сами, поскольку для этого не требовалось бы добавлять дополнительные локальные переменные и выскочить из стека.

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

Другие ответы также неверны, поскольку они не указывают, что оптимизация должна выполняться, когда и если окажется, что это необходимо, путем сравнения вашего приложения.

Единственная причина, по которой объявить локальные переменные, как вы это делали во втором случае, для удобства чтения и ясности.

Answer 2

Это очень микро-оптимизация, если только у вас нет узкого места в доступе к объекту. Однако, просто глядя на то, что происходит:

1.) Прямой доступ к собственности:

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

2.) Назначение местных жителей:

При назначении к локальным переменным, вы делаете поиск один раз, и работать с переменными в локальной области видимости, позже, который (должен быть) быстрее.

Вывод:

Второй вариант был бы более «эффективным», и если это важно для вас, гораздо более удобным для чтения, на мой взгляд. Кроме того, если вы повторно обращаетесь к тем же свойствам, имеет смысл сохранить их в локальных сетях - избавится от кучи повторения и с синтаксисом деструктурирования, на который действительно приятно смотреть.