current community

your communities

more stack exchange communities

Stack Exchange
tour help
Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.
up vote 0 down vote favorite
1

I have been using sizeof.js to investigate the size of various objects in javascript. It appears from this that the size of a function is essentially zero bytes, regardless of how many instructions the function executes. Why is this so?

share|improve this question
1  
What type of answer are you expecting when you do that? How would you suggest measuring the 'number of instructions'? How would this number be meaningful? –  MichaelT Nov 11 '14 at 2:06
    
I guess I don't understand how a function with a 1000 lines of code can occupy zero bytes in memory. Where is the function itself being stored? –  gloo Nov 11 '14 at 2:51

2 Answers 2

up vote 1 down vote accepted

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.

Asking how big something in a language like javascript which is often not compiled down too far becomes one of "how big is this parse tree", which doesn't have any real meaning at runtime... nor is it always accessible.

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.

Nor is the "how big is that function?" question asked of a javascript function pointer. It is. And whats more, under different javascript engines, if you could get a number, it would likely be different.

So:

  • 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.
share|improve this answer
    
Since in browsers, JavaScript files themselves are likely kept in memory, and since JavaScript clearly keeps function text around (because it can display it in the console log, web inspector, etc.) you can probably say in most cases, the function takes up at least as much space in memory as its text. If JIT is involved, there's probably a bit of additional overhead. In the end, I think it is meaningful in that memory is being used. It may just be impossible to determine the exact number in bytes. –  Steven Burnap Nov 11 '14 at 4:48
1  
Looking at the code of sizeof.js it's pretty clear that it's meant entirely as an estimate, not as any sort of controlled measure of truth. –  Steven Burnap Nov 11 '14 at 4:51
up vote 1 down vote

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.

In JavaScript, a function is just an object, and usually it is an object with no associated data members or child objects. So 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.

share|improve this answer
    
Note that C's sizeof won't tell you the size of a code segment either if you were to pass in a function pointer. –  MichaelT Nov 11 '14 at 5:11
    
Right, definitely. I agree with everything in your answer, but I thought it important to bring what sizeof.js was actually doing into the mix. –  Steven Burnap Nov 11 '14 at 5:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.