Nella maggior parte delle lingue, codice e dati sono cose diverse. Occupano diverse parti della memoria e non interagiscono tra loro.
Quando chiedi al codice "quanto è grande questo" stai chiedendo "quanto è grande l'oggetto istanziato". Osservando questo attraverso strumenti come sizeof.js, stai ponendo la domanda "quanto è grande l'oggetto che rappresenta il puntatore della funzione". E in questo caso, l'oggetto non ha proprietà aggiuntive, la sua dimensione è trascurabile.
Chiedere quanto grande in un linguaggio come javascript che spesso non è compilato troppo in profondità diventa uno di "quanto è grande questo albero di analisi", che non ha alcun significato reale in fase di esecuzione ... né è sempre accessibile .
Alcune lingue come Lisp, dove i dati e il codice possono mescolare un po 'più liberamente (il codice è dati), tale domanda può essere leggermente più significativa, anche se non proprio. Mentre sono sicuro che se avessi combattuto abbastanza a lungo (la mia vibrazione è un po 'arrugginita e non ho mai approfondito il regno della metaprogrammazione chiara), potrei inventare:
(defun double (x) (* x 2))
(print (somefunc 'double))
tale da stampare un valore di 2 o 4 a seconda di come si desidera definirlo. Ma non è un numero significativo nella maggior parte dei casi.
Né è "quanto è grande quella funzione?" domanda posta di un puntatore a funzione javascript. È. E cosa c'è di più, con diversi motori javascript, se potrebbe ottenere un numero, sarebbe probabilmente diverso.
sizeof.js ti sta solo fornendo una stima del ballpark, non una misura definitiva del numero di byte effettivamente utilizzati. La quantità effettiva di memoria utilizzata sarà l'implementazione. Vedi questo commento nella parte superiore della sizeof.js source :
/* Returns the approximate memory usage, in bytes, of the specified object.
Guarda la fonte. Tutto ciò che sta facendo è usare una semplice euristica. Assume bool sono quattro byte, i numeri sono otto byte e le stringhe sono due byte per carattere. Alcuni o tutti questi potrebbero essere sbagliati. (Soprattutto la stima della dimensione della stringa in quanto chiaramente non assume alcun Unicode interessante.) Se ottiene un oggetto, lo tratta come un albero, sommando le dimensioni annotate sopra ai membri non-object e quindi aggiungendo la dimensione degli oggetti figlio nello stesso modo.
Questo è abbastanza decente se vuoi un preventivo. Quello che è non che ti dà è tutto il sovraccarico usato per archiviare questa roba. Ad esempio, non vedi lo spazio utilizzato da tutti questi riferimenti agli oggetti.
In JavaScript, una funzione è solo un oggetto e di solito è un oggetto senza membri dati associati o oggetti figlio. Quindi sizeof.js stima la sua dimensione come zero. Questo non significa che la RAM fisica non venga utilizzata da esso. È quasi certamente, proprio come tutti gli altri overhead che vengono ignorati, come i veri puntatori nei riferimenti agli oggetti.
TL; DR - Questo non è come C sizeof , progettato nella lingua con un contratto per dirti esattamente quanti byte usare (beh, sorta). È una stima back-of-the-envelope che è buona solo per confrontare strutture e avere un'idea approssimativa dell'ambito.
Leggi altre domande sui tag functions javascript memory