We Keep Coding

In JavaScript What's the difference between variable having value and passing that value directly

I'm new to development, just need to know in terms of memory does it matter using a value without assigning in to a variable
Example 1:
var sendResponse = {
"a": 1,
"b": 2
};
res.send(sendResponse);
OR
res.send({
"a": 1,
"b": 2
});
Example 2:
var valueOne = "hi";
var valueTwo = "hithere";
if (someVariable == valueOne || someVariable == valueTwo) {
//
}
OR
if (someVariable == "hithere" || someVariable == "hi") {
//
}
Example 3:
var concatOne = "hi";
var concatTwo = "hithere";
var concatString = concatOne + concatTwo;
OR
var concatString = "hi" + "hithere";

Short answer:
It doesn't matter.
Cop-out answer:
What you're asking is basically the JavaScript equivalent of "How much memory does an rvalue take?" in C++, which has a good answer here.
Longer answer:
If you absolutely care about memory usage and performance then you shouldn't be using JavaScript in the first place (yes, modern JS JITs are very fast and are fast-approaching traditional AOT-compiled languages like C++, but there's still a huge memory tradeoff and first-run performance-hit for the JIT).
Secondarily, the kind of optimization you're referring to is a microoptimization - even if there are savings to be made by putting string-literals directly as arguments it would maybe save you maybe a handful of bytes for the entire script execution, compare that to the tens-to-hundreds of megabytes of memory that V8 will happily use (and that's still a fraction of the presumably dozens of gigabytes of RAM that your computer has).
(The technical details below are generalities and are not specific to V8 - which I'm not intimately familiar with, though I do have first-hand experience with the internals of Chakra from my time at Microsoft).
Some things to consider:
Most importantly: the JavaScript specification does not dictate how a JS engine is implemented. Someone could build a horribly inefficient engine that uses a gigabyte of internal memory for each variable and still comply with the spec. To give a perfect answer to your question would require a through and in-depth knowledge of V8's internals - and such knowledge would be outdated and obsolete within a few years anyway given how fast the JS ecosystem changes.
Most modern JavaScript engines (including V8) generally have 3 modes of operation:
Parsing.
Interpreted mode.
JIT mode.
Before a script can be executed it needs to be parsed: and when a script is being parsed any string-literals will be interned and kept in read-only memory (and so the string values consume a fixed, known, quantity of memory), which means that those values will never be destroyed by the GC.
Side-note: some systems (like Win32 and Prolog) refer to these as "string atoms" or "atomic strings" instead of "interned strings", with subtly different semantics.
(I accept that string-literals in dynamically evaluated scripts (namely in eval()) may be reclaimed - however I don't believe (but I could easily be wrong!) that any JS engines' GC today will free string literals that have no references pointing at them.
After a string literal has been interned it's possible for a JS engine's user-script variables to use some internal tagged reference type to succinctly refer to the string without needing to use a full 8-byte internal pointer (similar to, but not exactly nor necessarily a tagged pointer), there is also the possibility for small-string-optimization to be used (where a local copy of the entire string, if it's small enough, is used instead of a pointer or reference to the string - this is fairly commonplace in C++ to avoid the runtime costs of multiple indirection).
Don't conflate memory used by a reference or local to the memory used by the value.
Memory usage by references/locals is difficult to identify because any fairly decent JIT will perform a lot of operations entirely within CPU registers and other non-memory addresses - as well as predetermining many operations as though they were like C++ constexpr - so if a variable is elided away does it still use any memory? does it use "zero" bytes? that's more a philosophical question, imo.
(there's loads more I could write on this subject but it's 7am now and I'm off...)

Yes it does, Because when you declare a variable in JS we are not specifying the size that variable going to hold so it allocates a minimal space for every variable we create , as well as the names we give to every variable will also take some space. So in case of dynamic allocation its okay do that , But the second method in every example is the preferred one.
var concatOne = "hi";
var concatTwo = "hithere";
var concatString = concatOne + concatTwo;
here the "var" keywords does not know which data type your going to use so it will be allocated the most heights data type size like big int , and also the two variable names also holds some space.
But the another method is priffered to be a good practice with optimized memory use as well as shorter code size, which can improve your code working performance the compilation and run time will be considerably lower
var concatString = "hi" + "hithere";

Global Javascript Properties - memory usage

I'm building various d3.js dashboards which frequently refer to a javascript_properties.js file which includes properties such as:
var all_charts = (function() {
return {
width:860,
height:500,
from_date:"",
to_date:"",
highlight_color:"#00FFFF"
}
}());
I use these properties frequently within various functions.
My question is:
Is there any harm in calling each property direct every time I use it or would it be more efficient to declare a local variable at the beginning of each function if a property is going to be called more than once?
To show an example. A local variable:
var width = all_charts.width;
OR calling
all_charts.width
as many times as required during a function.
There may be little discernible difference?

This isn't about memory usage, it's about lookup time.
Yes, caching the property to a local variable may make it faster when using that repeatedly afterward, as the JavaScript engine doesn't have to traverse the scope chain up to the global level to find all_charts and then look up width on it.
But, it's unlikely to make a noticeable difference unless you're using these properties hundreds of thousands of times in the same function.
Side note: There's no point to the function in the all_charts code, what you have does exactly what this does, just more indirectly:
var all_charts = {
width:860,
height:500,
from_date:"",
to_date:"",
highlight_color:"#00FFFF"
};

How many globals make sense to be passed to the IIFE wrapper?

To which extent does it make sense to pass plenty of global values to an IIFE?
The common thing is just to pass 3 as far as I see everywhere (window, document and undefined).
But... would it make sense to pass more if they are used more than 10 times in the code just for the fact of minification?
In my case I found the global variable Math 14 times in the code. It would make sense to pass it to an IIFE in order to save 42 bytes. Which in this case is not a lot, but if we sum bit by bit different global variables, then it would always make sense to pass as many global variables as possible, right? (Symbol, Object, Error, Date, JSON...)
(function($, window, document, Math, undefined) {
$.fn.mydemo = function() {
};
}(jQuery, window, document, Math));
Then, why isn't this a common approach?
Update:
To explain the 42 bytes of reduction:
Math = 4 characteres
1 character = 1 byte
14 times Math = 56 bytes
Math will get replaced by a single character after minification
As the function can be defined as function($, w, d, m, u)
14 characters of the shorten word Math (m) = 14 bytes
56 - 14 = 42 bytes of reduction

First of all, those values are not IIFEs.
And this is not about “saving characters” by having shorter variables names inside the function (at least not mainly), but rather about variable lookup and the “cost” associated with it.
If you were to use f.e. document inside your function without passing it in, then first a variable named document would be searched in the scope of the function, and only when that fails, search would continue in the scope above that, and so on.
That is the reason for passing such objects as parameters into the function – so that a direct reference to them within the function scope exists, and they do not have to be looked up in higher outside scopes.
Sometimes, you might even see this used in such a form like this:
(function(document) {
// do something with document, such as:
document.foo();
document.bar = "baz";
})(document);
– in that form, it should be even more clear that this is not about saving characters in variable names. The object is still referred to as document inside the function (which makes it clear what it is supposed to represent – the global document object), and the only effect achieved by this is said shorter lookup.

There are a number of cases where it makes sense to pass variables to an IIFE.
Aliasing
Passing a variable to an IIFE allows you to rename the variable within the function. This is commonly seen when using jQuery, particularly when noConflict is used:
(function ($) {
//in here $ will be the same as jQuery
}(jQuery));
Aliasing also helps minifiers to minify code, when you see something like:
(function (document, slice, Math) {
...
}(document, Array.prototype.slice, Math));
The minifier can rename the parameters to whatever it wants, and save you bytes. For large scripts using these properties a lot, it can be significant savings when it gets turned into:
(function(a,b,c){...}(document,Array.prototype.slice,Math));
Portability
This is more of an edge case than a general rule, but it's common to see a global IIF in the form of:
(function (global /* or window */) {
...
}(this));
This allows for portability between node.js and the browser so that the global variable has the same name in both environments.
Character Savings
While I already mentioned that minifiers can reduce the character count by changing the names of aliases, you may want to do this manually if you're participating in a code golf challenge.
Reference Safety
If you're authoring a script that must work in whatever environment its dumped into (think google analytics), you'll want to be sure that the global methods you're calling are what you expect. Storing a reference to those functions by passing them as parameters is one way to preserve the reference to the functions from becoming overridden by a malicious or ignorant programmer.
To answer the question in your title:
How many globals make sense to be passed to the IIFE wrapper?
As many as you need and no more. If you need to alias one or two variables, pass one or two references. If you need to be sure that the global functions aren't being changed, you may end up with 100 parameters. There's no hard-and-fast rule on this.

would it make sense to pass more if they are used more than 10 times in the code just for the fact of minification?
If you care that much about minification, sure, why not?
The common thing is just to pass 3 as far as I see everywhere (window, document and undefined)
Yes, altough you see not passing document, or passing jQuery (aliased as $), just as often. And of course it's not only about minification, but about performance, and you only care for window and document on that behalf.
it would always make sense to pass as many global variables as possible, right?
Well, except you don't use them in your code. Symbol, Object, Error, Date, JSON, Math and the others are not needed that often in most code. And developers don't like to do those byte counts you are suggesting every time they change a bit of code, so this IEFE boilerplate just stays as it is (and imho there's much cargo cult to it).
You would let your minifier do this automatically if you'd really care.

Why do people use setTimeout("func()", ... ) instead of setTimeout(func, ... )

I see this used a lot and I was told putting the function reference between quotes was bad because setTimeout/setInterval evals the reference. What is the actual difference between these two such that one is used over the other and why do I see this used so frequently even though it should be common knowledge that this one way is bad?

People may not realize they can use the unquoted form.
The name referenced in the string may not yet be defined.
The quoted form gives you delayed execution:
setTimeout("myFunction(1, 'hello')", 100)
is easier to understand than:
setTimeout(function () { myFunction(1, 'hello') }, 100)
and this doesn't do what the author wants:
setTimeout(myFunction(1, 'hello'), 100)

There are two main differences between these two forms:
setTimeout("myFunc()", 100);
and
setTimeout(myFunc, 100);
The first is less efficient and it evaluates the function in the global scope so you can't pass it a local function or any function that isn't global.
In a look at the efficiency argument, if you wanted to call a function you had in your code would you write:
x = myFunc();
or would you write:
x = eval("myFunc()");
Of course, you'd write the first one because:
That's how you normally write javascript
The function reference can be resolved once in the first pass of the interpreter rather than each time it executes
Minifiers/optimizers can rename your symbol with the first, but not the second.
You can call local functions with the first one, but the second requires a global function
eval() is a fairly heavyweight thing that should be used only when there is no other better way to do it.
FYI, this jsPerf comparison indicates that the eval() version is 96% slower. The performance might not matter in some circumstances, but you can get the idea how much less efficient it is.

I bet it also prevents memory leaks.
Doesn't leak X:
var x = $("loading");
setTimeout("createTree(1);", 0);
Leak's X:
var x = $("loading");
setTimeout(function(){createTree(1);}, 0);

In javascript, is accessing 'window.Math' slower or faster than accessing the 'Math' object without the 'window.'?

I'm kind of curious about what the best practice is when referencing the 'global' namespace in javascript, which is merely a shortcut to the window object (or vice versia depending on how you look at it).
I want to know if:
var answer = Math.floor(value);
is better or worse than:
var answer = window.Math.floor(value);
Is one better or worse, even slightly, for performance, resource usage, or compatibility?
Does one have a slighter higher cost? (Something like an extra pointer or something)
Edit note: While I am a readability over performance nazi in most situations, in this case I am ignoring the differences in readability to focus solely on performance.

First of all, never compare things like these for performance reasons. Math.round is obviously easier on the eyes than window.Math.round, and you wouldn't see a noticeable performance increase by using one or the other. So don't obfuscate your code for very slight performance increases.
However, if you're just curious about which one is faster... I'm not sure how the global scope is looked up "under the hood", but I would guess that accessing window is just the same as accessing Math (window and Math live on the same level, as evidenced by window.window.window.Math.round working). Thus, accessing window.Math would be slower.
Also, the way variables are looked up, you would see a performance increase by doing var round = Math.round; and calling round(1.23), since all names are first looked up in the current local scope, then the scope above the current one, and so on, all the way up to the global scope. Every scope level adds a very slight overhead.
But again, don't do these optimizations unless you're sure they will make a noticeable difference. Readable, understandable code is important for it to work the way it should, now and in the future.
Here's a full profiling using Firebug:
<!DOCTYPE html>
<html>
<head>
<title>Benchmark scope lookup</title>
</head>
<body>
<script>
function bench_window_Math_round() {
for (var i = 0; i < 100000; i++) {
window.Math.round(1.23);
}
}
function bench_Math_round() {
for (var i = 0; i < 100000; i++) {
Math.round(1.23);
}
}
function bench_round() {
for (var i = 0, round = Math.round; i < 100000; i++) {
round(1.23);
}
}
console.log('Profiling will begin in 3 seconds...');
setTimeout(function () {
console.profile();
for (var i = 0; i < 10; i++) {
bench_window_Math_round();
bench_Math_round();
bench_round();
}
console.profileEnd();
}, 3000);
</script>
</body>
</html>
My results:
Time shows total for 100,000 * 10 calls, Avg/Min/Max show time for 100,000 calls.
Calls Percent Own Time Time Avg Min Max
bench_window_Math_round
10 86.36% 1114.73ms 1114.73ms 111.473ms 110.827ms 114.018ms
bench_Math_round
10 8.21% 106.04ms 106.04ms 10.604ms 10.252ms 13.446ms
bench_round
10 5.43% 70.08ms 70.08ms 7.008ms 6.884ms 7.092ms
As you can see, window.Math is a really bad idea. I guess accessing the global window object adds additional overhead. However, the difference between accessing the Math object from the global scope, and just accessing a local variable with a reference to the Math.round function isn't very great... Keep in mind that this is 100,000 calls, and the difference is only 3.6ms. Even with one million calls you'd only see a 36ms difference.
Things to think about with the above profiling code:
The functions are actually looked up from another scope, which adds overhead (barely noticable though, I tried importing the functions into the anonymous function).
The actual Math.round function adds overhead (I'm guessing about 6ms in 100,000 calls).

This can be an interest question if you want to know how the Scope Chain and the Identifier Resolution process works.
The scope chain is a list of objects that are searched when evaluating an identifier, those objects are not accessible by code, only its properties (identifiers) can be accessed.
At first, in global code, the scope chain is created and initialised to contain only the global object.
The subsequent objects in the chain are created when you enter in function execution context and by the with statement and catch clause, both also introduce objects into the chain.
For example:
// global code
var var1 = 1, var2 = 2;
(function () { // one
var var3 = 3;
(function () { // two
var var4 = 4;
with ({var5: 5}) { // three
alert(var1);
}
})();
})();
In the above code, the scope chain will contain different objects in different levels, for example, at the lowest level, within the with statement, if you use the var1 or var2 variables, the scope chain will contain 4 objects that will be needed to inspect in order to get that identifier: the one introduced by the with statement, the two functions, and finally the global object.
You also need to know that window is just a property that exists in the global object and it points to the global object itself. window is introduced by browsers, and in other environments often it isn't available.
In conclusion, when you use window, since it is just an identifier (is not a reserved word or anything like that) and it needs to pass all the resolution process in order to get the global object, window.Math needs an additional step that is made by the dot (.) property accessor.

JS performance differs widely from browser to browser.
My advice: benchmark it. Just put it in a for loop, let it run a few million times, and time it.... see what you get. Be sure to share your results!

(As you've said) Math.floor will probably just be a shortcut for window.Math (as window is a Javascript global object) in most Javascript implementations such as V8.
Spidermonkey and V8 will be so heavily optimised for common usage that it shouldn't be a concern.
For readability my preference would be to use Math.floor, the difference in speed will be so insignificant it's not worth worrying about ever. If you're doing a 100,000 floors it's probably time to switch that logic out of the client.
You may want to have a nose around the v8 source there's some interesting comments there about shaving nanoseconds off functions such as this int.Parse() one.
// Some people use parseInt instead of Math.floor. This
// optimization makes parseInt on a Smi 12 times faster (60ns
// vs 800ns). The following optimization makes parseInt on a
// non-Smi number 9 times faster (230ns vs 2070ns). Together
// they make parseInt on a string 1.4% slower (274ns vs 270ns).

As far as I understand JavaScript logic, everything you refer to as something is searched in the global variable scope. In browser implementations, the window object is the global object. Hence, when you are asking for window.Math you actually have to de-reference what window means, then get its properties and find Math there. If you simply ask for Math, the first place where it is sought, is the global object.
So, yes- calling Math.something will be faster than window.Math.something.
D. Crockeford talks about it in his lecture http://video.yahoo.com/watch/111593/1710507, as far as I recall, it's in the 3rd part of the video.

If Math.round() is being called in a local/function scope the interpreter is going to have to check first for a local var then in the global/window space. So in local scope my guess would be that window.Math.round() would be very slightly faster. This isn't assembly, or C or C++, so I wouldn't worry about which is faster for performance reasons, but if out of curiosity, sure, benchmark it.