chiusure javascript e posizionamento delle funzioni

Question

Il posizionamento di una funzione influisce sulle prestazioni delle chiusure nell'ambito? In tal caso, dov'è il posto ottimale per inserire queste funzioni? In caso contrario, l'associazione implicita per chiusura è motivo sufficiente per collocare logicamente una funzione in un altro posto?

Ad esempio, se foo non si basa sul valore di localState , il fatto che localState è accessibile da foo ha implicazioni su foo tempo di esecuzione, uso della memoria, ecc.?

(function(){
    var localState;

    function foo(){
        // code
    }

    function bar(){
        // code
        return localState;
    }
})();

In altre parole, sarebbe una scelta migliore, e se sì perché?

(function(){
    function foo(){
        // code
    }

    var localState;

    function bar(){
        // code
        return localState;
    }
})();

Darius Bacon ha suggerito sotto che i due esempi sopra sono identici poiché localState è possibile accedere ovunque all'interno del blocco. Tuttavia, l'esempio di seguito in cui foo è definito all'esterno del blocco potrebbe essere un caso diverso. Cosa ne pensi?

function foo(){
    // code
}

(function(){

    var localState;

    function bar(){
        // code
        foo();
        return localState;
    }
})();

Answer 1

Ogni funzione in Javascript è una chiusura. Il tempo di esecuzione per risolvere il valore di una variabile viene sostenuto solo se la funzione fa riferimento alla variabile. Ad esempio, in questo esempio la funzione y acquisisce il valore di x anche se x non fa riferimento direttamente a y:

var x = 3;
function y() eval("x");
y();
3

Answer 2

Entrambi questi frammenti sono equivalenti, perché sono entrambi definiti nello (stesso) ambiente della funzione anonima che stai creando. Penso che saresti in grado di accedere a localState da foo in entrambi i modi.

Detto questo ... se hai quantità assurde di variabili nell'ambiente che stai creando, il tempo di esecuzione di foo potrebbe essere influenzato, poiché la ricerca delle variabili richiederà probabilmente più tempo. Se ci sono tonnellate di variabili che non usi più nella funzione in cui definisci foo e foo non ne ha nemmeno bisogno, allora foo non causeranno la raccolta dei rifiuti, quindi potrebbe essere un problema.

Answer 3

Cane, spero che l'ordine delle dichiarazioni sia qualcosa che gli interpreti JavaScript potrebbero sottrarre. In ogni caso, se ci fosse una differenza di prestazioni, sarebbe così minimo da renderlo un figlio dei poster per i mali dell'ottimizzazione prematura.

Answer 4

Non penso che ci sarebbe alcun sovraccarico di prestazioni, poiché lo script java non usa la nozione di stack di funzioni. Supporta l'ambito lessicale. Lo stesso stato viene eseguito attraverso le chiamate di chiusura. In una nota a margine, nel tuo esempio non sembra che tu stia eseguendo alcuna istruzione!

Answer 5

L'ambito di una dichiarazione var o funzione è l'intero blocco in cui appare, indipendentemente da dove si trova la dichiarazione nel blocco; quindi sarebbe sorprendente che influisse sull'efficienza.

Cioè, non dovrebbe importare se " function foo () " è prima o dopo " var localState " all'interno di questo blocco. può importare se " function foo () " si trova in questo blocco o in un blocco (se può essere issato in un ambito superiore perché non usa nessuna variabili locali); dipende dai dettagli del tuo compilatore Javascript.

Answer 6

Nei tuoi esempi la differenza non conta davvero. Anche se foo è nell'ambito globale non avrai problemi.

Tuttavia, è utile tenere presente che se si utilizza lo stile di assegnazione di funzioni alle variabili per dichiarare le proprie funzioni, l'ordine in cui vengono dichiarate può diventare un bel problema.

Per un'idea migliore, prova i seguenti due esempi:

CheckOne();
function CheckOne() {
    alert('check...check one.');
}

CheckTwo();
var CheckTwo = function() {
    alert('check...check two.');
};

L'unica differenza tra il secondo e il primo è lo stile che usano per dichiarare le loro funzioni. Il secondo genera un errore di riferimento.

Saluti.