후자의 함수가 변수를 반복해서 작성해야하는 이유는 무엇입니까?

var toSizeString = (function() {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

  return function(size) {
    var gbSize = size / GB,
        gbMod  = size % GB,
        mbSize = gbMod / MB,
        mbMod  = gbMod % MB,
        kbSize = mbMod / KB;

    if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
    } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
    } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
    } else {
      return size + 'B';
    }
  };
})();

그리고 더 빠른 기능 : (반복적으로 동일한 변수 kb / mb / gb를 항상 계산해야함에 유의하십시오). 성능은 어디서 얻습니까?

function toSizeString (size) {

 var KB = 1024.0,
     MB = 1024 * KB,
     GB = 1024 * MB;

 var gbSize = size / GB,
     gbMod  = size % GB,
     mbSize = gbMod / MB,
     mbMod  = gbMod % MB,
     kbSize = mbMod / KB;

 if (Math.floor(gbSize)) {
      return gbSize.toFixed(1) + 'GB';
 } else if (Math.floor(mbSize)) {
      return mbSize.toFixed(1) + 'MB';
 } else if (Math.floor(kbSize)) {
      return kbSize.toFixed(1) + 'KB';
 } else {
      return size + 'B';
 }
};

최신 JavaScript 엔진은 모두 적시에 컴파일됩니다. "반복해서 다시 만들어야하는"항목에 대해서는 추정 할 수 없습니다. 이러한 종류의 계산은 어느 경우 에나 최적화하기가 비교적 쉽습니다.

반면에 상수 변수를 닫는 것은 일반적인 JIT 컴파일 대상이 아닙니다. 일반적으로 다른 호출에서 해당 변수를 변경하려는 경우 클로저를 만듭니다. 또한 멤버 변수에 액세스하는 것과 OOP의 로컬 int의 차이와 같은 변수에 액세스하기위한 추가 포인터 역 참조를 작성하고 있습니다.

이런 상황은 사람들이 "조기 최적화"라인을 버리는 이유입니다. 쉬운 최적화는 이미 컴파일러에 의해 수행됩니다.

변수는 싸다. 실행 컨텍스트와 범위 체인 은 비싸다.

본질적으로 "클로저로 인해"클로저로 요약되는 다양한 답변이 있으며, 본질적으로 사실이지만 문제는 구체적 으로 클로저와 관련 이 없으며 , 다른 범위에서 변수를 참조하는 함수가 있다는 사실입니다. windowIIFE 내부의 로컬 변수가 아닌 객체의 전역 변수 인 경우 동일한 문제가 발생합니다 . 사용해보십시오.

따라서 첫 번째 함수에서 엔진 이이 문장을 볼 때 :

var gbSize = size / GB;

다음 단계를 수행해야합니다.

1. size현재 범위에서 변수 를 검색 하십시오. (그것을 발견.)
2. GB현재 범위에서 변수 를 검색 하십시오. (찾을 수 없습니다.)
3. GB상위 범위에서 변수 를 검색 하십시오. (그것을 발견.)
4. 계산을 수행하고에 할당하십시오 gbSize.

3 단계는 변수를 할당하는 것보다 훨씬 비쌉니다. 또한,이에게 할 다섯 번 모두 두 번을 포함 GB하고 MB. 함수 시작 부분에서 별칭을 지정 var gb = GB하고 별칭을 대신 참조하면 실제로 약간의 속도 향상이 발생하지만 일부 JS 엔진은 이미이 최적화를 수행 할 수도 있습니다. 물론 실행 속도를 높이는 가장 효과적인 방법은 스코프 체인을 전혀 통과하지 않는 것입니다.

JavaScript는 컴파일러가 컴파일시에 이러한 변수 주소를 해석하는 정적 인 유형의 컴파일 된 언어와는 다릅니다. JS 엔진은 name 으로 해결해야 하며 , 이러한 조회는 매번 런타임에 발생합니다. 따라서 가능하면 피하십시오.

변수 할당은 JavaScript에서 매우 저렴합니다. 그 진술을 뒷받침 할 것이 없지만 실제로 가장 저렴한 작업 일 수 있습니다. 그럼에도 불구하고, 그것은 거의 없다는 것을 말하는 것이 안전 결코 하려고하는 것이 좋습니다 피하기 변수를 생성하는 단계; 해당 영역에서 수행하려는 거의 모든 최적화는 실제로 성능 측면에서 상황을 악화시킵니다.

하나의 예는 폐쇄와 관련이 있고 다른 하나는 그렇지 않습니다. 폐쇄 변수는 일반 변수처럼 작동하지 않기 때문에 클로저 구현은 다소 까다 롭습니다. 이것은 C와 같은 저수준 언어에서 더 분명하지만 JavaScript를 사용하여 설명하겠습니다.

클로저는 함수뿐만 아니라 클로저 한 모든 변수로 구성됩니다. 해당 함수를 호출하려면 모든 닫힌 변수를 제공해야합니다. 닫힌 변수를 나타내는 첫 번째 인수로 객체를받는 함수로 클로저를 모델링 할 수 있습니다.

function add(vars, y) {
  vars.x += y;
}

function getSum(vars) {
  return vars.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(adder, 2);
console.log(adder.getSum(adder));  //=> 42

어색한 호출 규칙을 참고 closure.apply(closure, ...realArgs)이 필요

JavaScript의 내장 객체 지원을 통해 명시적인 vars인수 를 생략하고 this대신 사용할 수 있습니다 .

function add(y) {
  this.x += y;
}

function getSum() {
  return this.x;
}

function makeAdder(x) {
  return { x: x, add: add, getSum: getSum };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

이러한 예제는 실제로 클로저를 사용하는이 코드와 동일합니다.

function makeAdder(x) {
  return {
    add: function (y) { x += y },
    getSum: function () { return x },
  };
}

var adder = makeAdder(40);
adder.add(2);
console.log(adder.getSum());  //=> 42

이 마지막 예에서 객체는 반환 된 두 함수를 그룹화하는 데만 사용됩니다. this결합은 무관하다. 숨겨진 데이터를 실제 함수로 전달하고 닫힌 변수에 대한 모든 액세스를 해당 숨겨진 데이터의 조회로 변경하는 클로저를 가능하게하는 모든 세부 사항은 언어에 의해 처리됩니다.

그러나 클로저 호출은 추가 데이터를 전달하는 오버 헤드와 관련이 있으며 클로저를 실행하면 캐시 캐시가 잘못되어 일반 변수와 비교할 때 일반적으로 포인터 역 참조로 인해 추가 데이터의 조회 오버 헤드가 발생하므로 놀랄 일이 아닙니다. 클로저에 의존하지 않는 솔루션이 더 잘 수행됩니다. 특히 클로저가 저장하는 모든 작업은 매우 저렴한 산술 연산이므로 파싱 중에도 계속 접힐 수 있습니다.