JavaScript-함수를 변수에 선언하는 것이 현명한 생각입니까?

예, 새 함수 인스턴스를 만들면 측정 가능한 오버 헤드가 있습니다. 이 오버 헤드가 실제 코드에서 차이를 만드는지 여부는 전적으로 또 다른 문제입니다.

예를 들어, 다소 비효율적 인 다양한 방식으로 부울 플래그를 전환하는 다음과 같은 간단한 벤치 마크를 고려해보십시오.

var suite = new Benchmark.Suite;
var flag = true;

suite.add('baseline', function() {
  flag = !flag;
});

suite.add('local helper function', function() {
  var f = function(x) { return !x };
  flag = f(flag);
});

var g = function(x) { return !x };
suite.add('external helper function', function() {
  flag = g(flag);
});

console.log('Running benchmark on ' + Benchmark.platform.description );
suite.on('cycle', function(event) { console.log(' - ' + event.target) });
suite.on('complete', function() { console.log('Fastest is ' + this.filter('fastest').map('name')) });
suite.run({ 'async': true });

<script src="https://cdn.jsdelivr.net/g/[email protected],[email protected],[email protected]"></script>

Chrome 52에서이 벤치 마크를 실행하면 다음과 같은 결과가 나타납니다.

Running benchmark on Chrome 52.0.2743.116 32-bit on Windows Server 2008 R2 / 7 64-bit
 - baseline x 75,600,376 ops/sec ±0.90% (62 runs sampled)
 - local helper function x 5,912,099 ops/sec ±0.36% (63 runs sampled)
 - external helper function x 74,912,931 ops/sec ±1.05% (62 runs sampled)
Fastest is baseline,external helper function

놀랍게도 기준 코드와 변수를 토글하기 위해 외부 함수를 호출하는 버전은 거의 똑같이 빠릅니다. 그 차이는 통계적으로 유의하지 않으며 (즉, 랜덤 노이즈와 효과적으로 구분할 수 없음) 벤치 마크 라이브러리 는 둘 다 1 위를 차지한 것으로보고합니다. Chrome의 JS 엔진이 외부 도우미 기능을 인라인하여 두 버전을 효과적으로 동일하게 만들 수있는 것 같습니다. 그러나 모든 반복에서 새 도우미 함수 인스턴스를 만들고 호출하는 버전은 함수를 만들고 호출하는 오버 헤드를 반영하여 거의 13 배의 시간이 걸립니다.

즉, 13 배 오버 헤드는 참 / 거짓 플래그를 토글하는 사소한 작업과 비교됩니다. 약간 더 현실적인 사용 사례를 시뮬레이션하기 위해 벤치 마크 코드에 간단한 DOM 쿼리를 추가하면 어떤 일이 발생하는지 살펴 보겠습니다.

var suite = new Benchmark.Suite;
var flag = true;

suite.add('baseline', function() {
  var foundElements = document.querySelectorAll("*");
  flag = !foundElements;
});

suite.add('local helper function', function() {
  var f = function(x) { return !x };
  var foundElements = document.querySelectorAll("*");
  flag = f(foundElements);
});

var g = function(x) { return !x };
suite.add('external helper function', function() {
  var foundElements = document.querySelectorAll("*");
  flag = g(foundElements);
});

console.log('Running benchmark on ' + Benchmark.platform.description );
suite.on('cycle', function(event) { console.log(' - ' + event.target) });
suite.on('complete', function() { console.log('Fastest is ' + this.filter('fastest').map('name')) });
suite.run({ 'async': true });

<script src="https://cdn.jsdelivr.net/g/[email protected],[email protected],[email protected]"></script>

이번에는 결과가 다음과 같습니다.

Running benchmark on Chrome 52.0.2743.116 32-bit on Windows Server 2008 R2 / 7 64-bit
 - baseline x 898,041 ops/sec ±25.49% (39 runs sampled)
 - local helper function x 605,107 ops/sec ±30.57% (47 runs sampled)
 - external helper function x 720,695 ops/sec ±34.60% (38 runs sampled)
Fastest is baseline,external helper function

예, 순위는 여전히 동일하지만 (타이밍에 대한 차이는 훨씬 높지만) 이제 내부 도우미 기능이있는 버전은 외부 도우미 기능을 사용하는 버전보다 약 20 % 느립니다. (아직도 예상했던 것보다 많은데, querySelectorAll()적어도이 스 니펫과 같은 정말 간단한 문서에서는 꽤 빠릅니다.) 그리고 실제로 DOM 요소로 작업을 수행 하기 위해 코드를 더 추가 하면 상대적 차이가 훨씬 더 작아집니다. 아직도.

예, 헬퍼 함수를 ​​호출하는 다른 함수 내부 또는 외부에서 정의 할 수 있고 (그리고 자체적으로 반복적으로 호출 됨) 다른 옵션보다 하나의 옵션을 선호 할 다른 이유 가 없는 경우 다음을 유지하는 것이 좀 더 효율적입니다. 함수 객체의 반복 생성을 방지하고 JS 엔진의 인라인을 더 쉽게 만들기 위해 외부에 정의합니다. 그러나 실제로는,하지 않는 한이 중첩 된 함수임을 알 정확하게 코드의 성능이 중요한 부분, 당신은 아마 그것에 대해하지 걱정해야한다.