I've heard alot of people saying that accessing the arguments object is expensive. (example: Why was the arguments.callee.caller property deprecated in JavaScript?)
Btw what exactly does that statement mean at all? isn't accessing the arguments object simply a simple property lookup? what exactly is the big deal?
The big deal is at least twofold:
1) Accessing the arguments object has to create an arguments object. In particular, modern JS engines don't actually create a new object for the arguments every time you call a function. They pass the arguments on the stack, or even in machine registers. As soon as you touch arguments, though, they have to create an actual object. This is not necessarily cheap.
2) Once you touch the arguments object, various optimizations that JS engines can otherwise perform (e.g. detecting cases in which you never assign to an argument and optimizing that common case) go out the window. Every access to the function arguments, not just ones through arguments becomes much slower because the engine has to deal with the fact that you might have messed with the arguments via arguments.
I have also never heard a serious explanation for why accessing the arguments object is expensive. However, this site: http://www.playmycode.com/blog/2011/03/simple-yet-effective-javascript-optimisations/ notes that arguments is not really an array and is less efficient than accessing an array. The above linked site even suggests converting arguments to an array as an optimization.
Going to check with those who know JS interpreters more intimately...
Related
Background
I'm the maintainer of a low level library for fast object traversal in Node.js. The focus of the library is speed and it is heavily optimised. However there is one big slowdown: Callback Parameters
The Problem
Callbacks are provided by the library consumer and can be invoked many, many times per scan. For every invocation all parameters are computed and passed to the callback. In most cases only a fraction of the parameters are actually used by the callback.
The Goal
The goal is to eliminate the unnecessary computation of these parameters.
Solutions Ideas
Ideally NodeJs would expose the callback parameters as defined by the callback. However obtaining them doesn't seem to be possible without a lot of black magic (string parsing). It would also not solve the situation where parameters are only required conditionally.
Instead of trying to obtain the parameters from the callback, we could require the callback to expose the required parameters. It sounds very inconvenient and error prone and would also not solve conditionally requires.
We could introduce a different callback for every parameter combination. This sounds like a bad idea.
Instead of passing in the parameters directly, we could pass in a function for each parameter that computes and returns the parameter value. Inside the callback the parameter would then be invoked as required. It's ugly but might be the best approach?
Questions
How do other libraries solve this?
What are other ways this can be solved?
This is a very fundamental design decision and I'm trying to get this right.
Thank you very much for your time! As always appreciated!
You could pass to the callback an object that has various methods on it that the client using the callback could call to fetch whatever parameters they actually need. That way, you'd have a clean object interface and you'd only compute the necessary information that was actually requested.
This general design pattern is sometimes called "lazy computation" where you only do the computation as required. You can use either accessor functions or getters, depending upon the type of interface you want to expose.
For performance reasons, you can perhaps reuse the same object for each time you call the callback rather than building a new one (depends upon details of your implementation).
Note that you don't even have to put all the information needed for the computation into the object itself as the methods on the object can, in some cases, refer to your own local context and locally scoped variables when doing their computation.
However there is one big slowdown: Callback Parameters
Did you actually benchmark this? I doubt constructing the argument values is that costly. Notice that if this is a really heavily used call, V8 might be able to inline it and then optimise away unused argument values.
Ideally NodeJs would expose the callback parameters as defined by the callback.
Actually, it does. If you do want to rely on this property though, you should properly document that you do, otherwise this magic could lead to obscure bugs.
We could introduce a different callback for every parameter combination. This sounds like a bad idea.
It doesn't seem to be that much of a problem to provide two options, filter(key, value) and filterDetailed(key, value, context). If the optimisation is really worth it, and as you say this is a low-level library, just go for it.
Instead of passing in the parameters directly, we could pass in a function for each parameter that computes and returns the parameter value. Inside the callback the parameter would then be invoked as required. It's ugly but might be the best approach?
Constructing a closure object to pass instead of a parameter does have some overhead as well, so you will need to benchmark this properly. It might not be worth it.
However, I see that you are actually passing a single context object as the argument on which the computed values are accessed as properties. In that case, you can simply make these properties getters that will compute the value when they are accessed, not when the object is constructed.
I'm currently writing a library of extension methods to many different Javascript objects. Is there any performance considerations if, for example, i add over 200 methods to different objects (through their prototypes) in the same source file?
EDIT: Just for information, i'm extending the built-in objects.
No, there will be almost no performance hit. Even attaching the functions to the prototype(s) should only take a few ms (maybe 5ms) and beyond that you have 200 functions sitting in memory in one spot, never being copied, you will never notice anything. Assuming, of course, that you are attaching to .prototype of something.
As for why there is no speed hit: In order to resolve a function call on an object: foo.doSomething(), the internal engine needs to walk the object scope and prototype chain of that object. Basically, it does this:
if(Object.hasOwnProperty('doSomething')){ // run Object.doSomething
if(Object.__proto__.hasOwnProperty('doSomething')){ // run Object.__proto__.doSomething
while(Object.__proto__.__proto__.__proto__.....){ // repeat
Every layer of this is a hash, so lookups are constant time. In terms of lookup speed, it doesn't matter if there's 2 or 2 million functions in a prototype chain (Although if you have 2 million you'll be eating tons of memory).
For reference: jQuery has 511 functions internally. 200 isn't that many at all
Side note: DO NOT EXTEND Object.prototype -- JUST DON'T. You break for-in loops if you do this, or at least come very close to breaking them if people don't use explicit if(obj.hasOwnProperty(foo)) checks. You'll also make for-in loops slower on object hashes which is the ONLY potential slow-down you'll ever encounter extending prototypes.
And PLEASE don't extend Array.prototype -- it annoys me. But plenty of other people do it, so it's not -as- bad... The argument is that you're not supposed to use for-in loops on Arrays, and many people now don't because of Prototype.js, but you should still be allowed to if you want to!
Looking at a lot of NodeJS and Javascript code recently, it seems arguments is not an instance of Array but still behaves like one, so people do stuff like Array.prototype.slice.call(arguments, ...) or [].slice.call(arguments) which adds verbosity and increases hurdle for newbies to understand etc.. Is there a reason why arguments isnt an instance of Array or is this just one those bad parts?
NO. arguments is a standalone object that just so happens to have a length property and the ability to use [] to index it. But otherwise, it is just an object, not an Array object.
And yes, this is indeed one of the bad parts of JavaScript.
Since it seems like the first thing people do is convert arguments into a real array, I'm interested in why the Javascript language authors and implementers decided, and continue to think, that arguments should not be a real Array. I don't mean this as flamebait, I'm sincerely interested in the thinking behind it. Since the function is naturally being called when you're in its body, I don't think it's because the objects arguments are referencing can change, like with some of the DOM results...
My conjecture:
The concept of the arguments object has been on the language since the very beginning, it's even described in the ECMAScript First Edition Standard(PDF).
In that version of ECMAScript, the Array.prototype was really basic, array objects contained only 4 methods!: toString, join, reverse and sort.
I think that's one of the major reasons about they make arguments to inherit from Object.prototype, at that time those Array methods didn't look too useful.
But the Array.prototype object was extended in the next versions of the standard, now on ES5, Array objects have methods such as map, reduce, every, some, etc, that are really powerful.
The last year, there was a proposal in ES5 to make arguments inherit from Array.prototype, in the draft stages of the standard, but was dropped off time later.
In those drafts, arguments inherited from Array.prototype, but for backwards compatibility with ES3, the arguments object had defined two own properties, toString and toLocaleString, both pointing to the same methods on Object.prototype, but finally, the committee decided to keep inheriting from Object.prototype.
The arguments object has the very unusual feature that its array-like elements are synonyms for the local variables that hold the function arguments. For example:
function f(x) {
console.log(arguments[0]); // Displays the initial value of the argument x
x = 5; // Changes the value of the local variable x
console.log(arguments[0]); // Now displays 5
}
I always had the impression that this "magical behaviour" is the reason why arguments is not an array.
It's important to note that without one of the designers present, we can only really conjecture why. But we can come up with some decent reasons... here's mine:
From the perspective of a function, one reason could be because you can't - obviously - actually change the arguments that were passed into you. You could change an array that represents the arguments passed into you, but the arguments as they were passed is set in stone before you ever receive execution scope.
You can splice, dice and pop arrays, and if you did that to the arguments object then you just ruined what is conceptually an immutable structure (sad face!). The design of the real arguments object is closer to a kind of immutability JavaScript can offer.
It is similar to querystring parameters. You get a collection handed to you by the client sending the request. It's part of the request information, which is already set and done.
arguments doesn't just return the arguments. It returns callee object, and the array of arguments. If it were just an array, the first element might be the callee object and be more confusing.
In other words, what options do I have to allocate memory in JavaScript?
I know you can allocate memory either globally, or inside function scope. Can I allocate memory dynamically? What does the new operator really mean?
Edit: here's a specific example. How would you implement reading an integer value from the user - n, and then read n integers into an array?
you can't allocate memory. you can create objects. that's what new does.
now, javascript is a queer creature: functions are also objects in javascript. So this mean that you can instantiate prettymuch everything using new.
So, the new operator means that a new object is being created.
Javascript also garbage-collects these variables, just like it happens in java. So if you know java, it should be easy for you to draw parallels.
cheers,
jrh
PS: when you allocate objects, you really are allocating memory. Only, you are not doing that explicitly. You can allocate an array, and make it behave like a memory buffer, but that will degrade javascript performance drastically: javascript arrays are not in-memory buffers, they are also objects (like everything else).
JavaScript has garbage collection and handles this for you.
However, you can help it by using the delete operator where appropriate.
From the Apple JavaScript Coding Guidelines:
Just as you used the new operator to
create an object, you should delete
objects when you are finished with
them, like this:
delete myObjectVariable;
The JavaScript runtime automatically
garbage collects objects when their
value is set to null. However, setting
an object to null doesn’t remove the
variable that references the object
from memory. Using delete ensures that
this memory is reclaimed in addition
to the memory used by the object
itself. (It is also easier to see
places where your allocations and
deallocations are unbalanced if you
explicitly call delete.)
Steve
Hmmm sounds to me like you are coming from the memory focused language and trying to shoe horn that logic into JS. Yes JS uses memory (of course), but we have garbage collection to take care of cleaning it all up.
If you are after specifics about the guts of memory allocation then you will have to hunt around for that. But as a rule thumb, when you use var, new or declaring a new function (or closure) you are gobbling up memory. You can get vars to null to flag them for garbage collection and you can use the delete keyword too although few do either of these unless they work Server-side (like myself with ASP JScript) where its important.
Javascript is really, really friendly — really, too friendly by half!
If you have an array of 3 elements, and you want to add a fourth, you can just act as if that array location already exists:
var arr = ['zero', 'one', 'two'];
// Now you have arr[0], arr[1] and arr[2].
// arr.length is equal to 3.
.
// to add arr[8]:
arr[8] = 'eight';
// Now you have arr[0] through arr[8]. arr.length is equal to 9.
// and arr[3] through arr[7] exist, and
// are initialized to undefined. (If I remember right.)
So being really specific with memory allocation is unnecessary when adding elelments.
No, you don’t need to and can’t allocate memory. The JavaScript interpreter does that automatically.
To answer the title of the question, if you are to trust in MDN, most JavaScript implementations have a heap:
Heap
Objects are allocated in a heap which is just a name to denote a large
mostly unstructured region of memory.
Several Runtimes Communicating Together
A web worker or a cross-origin iframe has its own stack, heap, and
message queue. Two distinct runtimes can only communicate through
sending messages via the postMessage method. This method adds a
message to the other runtime if the latter listens to message events.
For a deeper dive into memory management, there is also an article here although much of this is implementation specific.
You do not need to manually manage memory in Javascript. Both heap and stacks are used under the hood to manage memory and it depends on the implementation. Usually, local variables are on the stack and objects are on the heap.