로컬 최적화에 미세 최적화 기능이 없습니까?

Question

내부 함수를이 외부로 이동하여 함수가 마이크로 최적화라고 할 때마다 생성되지 않도록할까요?

이 경우에 doMoreStuff 기능은 doStuff에서만 사용됩니다. 이런 지역의 기능에 대해 걱정해야합니까?

function doStuff() { 
    var doMoreStuff = function(val) { 
     // do some stuff 
    } 

    // do something 
    for (var i = 0; i < list.length; i++) { 
     doMoreStuff(list[i]); 
     for (var j = 0; j < list[i].children.length; j++) { 
       doMoreStuff(list[i].children[j]); 
     } 
    } 
    // do some other stuff 

} 

actaul 예를 말할 것이다 :

function sendDataToServer(data) { 
    var callback = function(incoming) { 
     // handle incoming 
    } 

    ajaxCall("url", data, callback); 

} 

Answer 1

이 범주 "마이크로 최적화"에 해당하는 경우 확실하지. 나는 안된다고.

그러나 얼마나 자주 전화할지는 doStuff에 달려 있습니다. 자주 호출하면 함수를 반복 작성하는 것이 불필요하며 오버 헤드가 추가됩니다. 당신이 전역 범위에서 "도우미"기능을 가지고 있지만 그것을 다시 피하지 않으려면

, 그렇게처럼 포장 할 수 있습니다 반환되는 함수로

var doStuff = (function() { 
    var doMoreStuff = function(val) { 
     // do some stuff 
    } 
    return function() { 
     // do something 
     for (var i = 0; i < list.length; i++) { 
      doMoreStuff(list[i]); 
     } 
     // do some other stuff 
    } 
}()); 

는 폐쇄, 그것은 doMoreStuff에 액세스 할 수 있습니다. 외부 함수는 즉시 실행됩니다 ( (function(){...}())). 책 JavaScript Patterns에서 찾을 수 있습니다 캡슐화, 객체 생성 패턴과 다른 개념에 대한

var stuff = { 
    doMoreStuff: function() {...}, 
    doStuff: function() {...} 
}; 

---

더 많은 정보 :

가 아니면 기능에 대한 참조를 유지하는 개체를 만듭니다.

Answer 2

그것은 완전히 함수가 호출하는 빈도에 따라 달라집니다. 초당 10 번 호출되는 OnUpdate 함수 인 경우 적절한 최적화입니다. 페이지 당 3 번 호출되면 미세 최적화입니다.

중첩 된 함수 정의는 필요하지 않지만 (함수에 대한 추가 인수로 바꿀 수 있음) 편리합니다. 중첩 된 함수와

예 : 대신 인수 이제

function somefunc() { 
    var localvar = 5 

    var otherfunc = function() { 
     alert(localvar); 
    } 

    otherfunc(); 
} 

똑같은 :

function otherfunc(localvar) { 
    alert(localvar); 
} 

function somefunc() { 
    var localvar = 5 

    otherfunc(localvar); 
} 

Answer 3

이것은 절대 최적화입니다. 처음부터 기능을하는 데 대한 모든 이유는 코드를보다 깨끗하고 유지 보수하기 쉽고 읽기 쉽게 만들어주는 것입니다. 함수는 코드 섹션에 의미 론적 경계를 추가합니다. 각 기능은 한 가지만 수행해야하며 제대로 수행해야합니다. 따라서 여러 기능을 동시에 수행하는 기능을 발견하면 여러 기능을 리팩토링하여 여러 가지 루틴으로 사용할 수 있습니다.

너무 느린 작업이있을 때만 최적화하십시오 (아직 작동하지 않는 경우 기간을 최적화하기에는 너무 이르다). 아무도 그들의 요구/요구 사항보다 빠른 프로그램을 위해 추가 비용을 지불하지 않았다는 것을 기억하십시오 ...

편집 : 프로그램이 아직 끝나지 않았다고 생각하면 조기에 최적화 된 것입니다. 왜 그렇게 나쁜거야?글쎄요, 우선 장기적으로 중요하지 않은 일에 시간을 할애하고 있습니다. 둘째, 최적화를 통해 현실적인 의미에서 개선 된 사항을 확인할 수있는 기준이 없습니다. 셋째, 유지 보수성과 가독성을 줄이기 전에이를 줄이는 것이므로 명확한 간결한 코드를 사용하는 것보다 실행하기가 어려울 수 있습니다. 넷째, 프로그램을 끝내고 모든 요구 사항을 이해할 때까지 프로그램의 다른 부분에 doMoreStuff이 필요한지 여부는 알 수 없습니다 (정확한 세부 사항에 따라 길어질 수는 있지만 가능성은 없습니다). 빠른 "벤치 마크는"평균 PC에서 실행

Answer 4

Donnald 크 누스 조기 최적화는 모든 악의의 루트 말했다 이유가있다

는 ... (난, 많은 변수 불명이 거기에 알고 이렇게 명백한에 코멘트를 해달라고하지만) 어떤 경우에 흥미로운 :

count = 0; 
t1 = +new Date(); 
while(count < 1000000) { 
    p = function(){}; 
    ++count; 
} 
t2 = +new Date(); 
console.log(t2-t1); // milliseconds 

는하지 않지만 그것은 약 100 밀리 초에 의해 아래로 실행 시간을 가져온다 (예를 들어 조건에 증가를 이동하여 최적화 할 수 영향을 수 있습니다 와 기능을 생성하지 않고 트윈, 그래서) 3 회가 준 실행

정말 관련이 없습니다 :

913 
878 
890 

다음 함수 생성 줄을 주석으로, 3 개 실행은 준 :

462 
458 
464 

그래서 순수하게 1000,000 개의 빈 함수 생성에 약 0.5 초를 더합니다. 원래 코드가 핸드 헬드 장치에서 초당 10 회 실행된다고 가정하더라도 (장치의 전반적인 성능은이 노트북의 1/100로 과장되어 있다고 가정 해 봅시다 - 좋은 상한을 제공 할지라도 1/10에 가까울 것입니다) ,이 컴퓨터에서 1000 개의 함수 생성/초에 해당합니다.이 속도는 1/2000 초입니다. 매 초당 핸드 헬드 장치가 1/2000 초의 처리 오버 헤드를 추가하고 있습니다. 매초 반 밀리 초가 그리 많지 않습니다.

이 원시 테스트에서 필자는 PC에서 이것은 분명히 마이크로 최적화라고 결론을 내릴 것입니다. 약한 장치 용으로 개발한다면 거의 확실합니다.

Answer 5

원래 질문은 2011 년에 제기되었습니다. 그 이후로 Node.js의 등장으로 인해 문제를 다시 검토 할 가치가 있다고 생각했습니다. 서버 환경에서 몇 밀리 초 정도면 여기에서 많은 문제가 발생할 수 있습니다. 부하가있는 상태에서 반응성이 유지되는 것과 그렇지 않은 것간에 차이가있을 수 있습니다.

내부 기능이 개념적으로 훌륭하지만 JavaScript 엔진의 코드 최적화 프로그램에 문제가 발생할 수 있습니다. 다음의 예는 이것을 설명 :

function a1(n) { 
    return n + 2; 
} 

function a2(n) { 
    return 2 - n; 
} 

function a() { 
    var k = 5; 
    for (var i = 0; i < 100000000; i++) { 
     k = a1(k) + a2(k); 
    } 
    return k; 
} 

function b() { 
    function b1(n) { 
     return n + 2; 
    } 

    function b2(n) { 
     return 2 - n; 
    } 

    var k = 5; 
    for (var i = 0; i < 100000000; i++) { 
     k = b1(k) + b2(k); 
    } 
    return k; 
} 

function measure(label, fn) { 
    var s = new Date(); 
    var r = fn(); 
    var e = new Date(); 
    console.log(label, e - s); 
} 

for (var i = 0; i < 4; i++) { 
    measure('A', a); 
    measure('B', b); 
} 

코드를 실행하기위한 명령을

node --trace_deopt test.js 

출력 : 당신이 볼 수 있듯이

[deoptimize global object @ 0x2431b35106e9] 
A 128 
B 130 
A 132 
[deoptimizing (DEOPT eager): begin 0x3ee3d709a821 b (opt #5) @4, FP to SP delta: 72] 
    translating b => node=36, height=32 
    0x7fffb88a9960: [top + 64] <- 0x2431b3504121 ; rdi 0x2431b3504121 <undefined> 
    0x7fffb88a9958: [top + 56] <- 0x17210dea8376 ; caller's pc 
    0x7fffb88a9950: [top + 48] <- 0x7fffb88a9998 ; caller's fp 
    0x7fffb88a9948: [top + 40] <- 0x3ee3d709a709; context 
    0x7fffb88a9940: [top + 32] <- 0x3ee3d709a821; function 
    0x7fffb88a9938: [top + 24] <- 0x3ee3d70efa71 ; rcx 0x3ee3d70efa71 <JS Function b1 (SharedFunctionInfo 0x361602434ae1)> 
    0x7fffb88a9930: [top + 16] <- 0x3ee3d70efab9 ; rdx 0x3ee3d70efab9 <JS Function b2 (SharedFunctionInfo 0x361602434b71)> 
    0x7fffb88a9928: [top + 8] <- 5 ; rbx (smi) 
    0x7fffb88a9920: [top + 0] <- 0 ; rax (smi) 
[deoptimizing (eager): end 0x3ee3d709a821 b @4 => node=36, pc=0x17210dec9129, state=NO_REGISTERS, alignment=no padding, took 0.203 ms] 
[removing optimized code for: b] 
B 1000 
A 125 
B 1032 
A 132 
B 1033 

이 기능 A와 B가 동일한에서 실행 속도. 그런 다음 어떤 이유로 인해 최적화 해제 이벤트가 발생했습니다. 그때부터 B는 거의 한 단계 더 느려집니다.

성능이 중요한 코드를 작성하는 경우 내부 기능을 피하는 것이 가장 좋습니다.