I have been using
In most languages, code and data are different things. They occupy different parts of memory and don't interact with each other.
When you ask the code "how big is this" you are asking about "how big is the instantiated object". When looking at this you through tools like sizeof.js, you are asking the question "how big is the object representing the function pointer". And in this case, the object doesn't have any additional properties its size is negligible.
Some languages such as Lisp, where the data and code can mix a bit more freely (the code is data), such a question can be slightly more meaningful, though not really. While I'm sure if I fought with it long enough (my lisp is a bit rusty and I never delved into that realm of lisp metaprogramming), I could come up with:
(defun double (x) (* x 2)) (print (somefunc 'double))
such that it would print out a value of 2, or 4 depending on how you wanted to define that. But it's not a meaningful number in most cases.
- The question you are asking of sizeof.js is giving you back the right number.
- The object that represents the function pointer has no appreciable size associated with it.
- Hypothetically, it could have data that wasn't the code associated with it and you would get back a different number.
- The code lives in a different spot in memory than the data that sizeof.js may not have a way to access.
- The size of the code isn't a meaningful number within the runtime.
sizeof.js is just giving you a ballpark estimation, not a definitive measure of how many bytes are actually used. The actual amount of memory used is going to be implementation. See this comment at the top of the sizeof.js source:
/* Returns the approximate memory usage, in bytes, of the specified object.
Look at the source. All it is doing is using a simple heuristic. It assumes bools are four bytes, numbers are eight bytes and strings are two bytes per character. Any or all of these could be wrong. (Especially the string size estimation as it's clearly assuming no interesting Unicode.) If it gets an object, it just treats its as a tree, adding up the sizes noted above non-object members and then adding the size of child objects in the same way.
This is decent enough if you want an estimate. What it is not giving you is all the overhead used to store this stuff. You aren't seeing the space used by all these references to objects, for instance.
sizeof.js estimates its size as zero. This does not mean no physical RAM is being used by it. It almost certainly is, just like all the other overhead that's being missed, like the actual pointers in object references.
TL;DR - This is not like C
sizeof, designed into the language with a contract to tell you exactly how many bytes to use (well, sorta.) It's a back-of-the-envelope estimate that's good for only comparing structures and getting a rough idea of scope.