I'm doing some testing and optimizing on a JavaScript function I made. I notice that the add-on I'm using in Firefox (FireUnit) gives a return of the number of calls done during the profiling time. Is this the number of http calls made by the script?
Also, can you outline/discuss/grade/explain as to how many calls is considered within a good range? Maybe by giving examples or commonly-used JavaScript functions such as drop-down menus, hide/show images, image slideshow functionality, etc...
Does a call represent any measure of 'work' or merely the iterations performed?
In this context, a call is the amount of times a function has been invoked.
function foo() {
};
foo();
foo();
The function foo has been called/ invoked twice in the above example.
There is no answer for "what is a good range of calls". A function like jQuery will most likely be called a large number of times per page, whereas you would expect a function like init() to be called only once.
A better representation of the efficiency of your functions is their execution time; this records the amount of time taken for the function to execute (almost always recorded in milliseconds). Functions with long execution times could be optimized to lower their execution time and improve the efficiency of your program.
To best spend you time, you could combine the two statistics (call count and execution time), and look at optimizing the functions that are called a large number of times, and have longer execution times.
The number of calls means how many times a given function was run or invoked or executed. There is no good range in the number of calls. This number gives you two most important informations:
First, if some function is called only once and some other function is called 100 times then every optimization in the latter is 100 times more important than in the former. It is often a waste of time to optimize a function called only once, but if a function is called a lot of times then it may be important to see if it is not too slow.
The second thing you can see from the number of function calls is that if some function is called hundreds of times when in fact it always has the same result then it might mean that you are calling it inside a loop when calling it once and storing the value in a variable might be sufficient.
For example this would call the expensiveFunction 1000 times:
for (i = 0; i < 1000; i++) {
array[i] = i + expensiveFunction();
}
While this would call it only once:
value = expensiveFunction();
for (i = 0; i < 1000; i++) {
array[i] = i + value;
}
Seeing that some of your functions was called a lot of times might be a hint that you have some code similar to that example. Of course you can't cache the value every time but sometimes you do and knowing the number of function calls can be useful.
Related
I'm really new to JS and I'm having a lot of trouble writing/understanding callback functions
Let's say for example, I have the following code, but i dont want
takeNumbersGreaterThan(5);
to be executed until
insertNumbers();
is finished
numbers = [];
greaterThan = [];
insertNumbers();
takeNumbersGreaterThan(5);
insertNumbers(){
for (var i = 0; i<11; i++)
{
numbers.push(i)
}
}
takeNumbersGreaterThan(number){
for (var m = 0; m<numbers.length; m++)
{
if (numbers[m] > number)
{
greaterThan.push(numbers[m])
}
}
}
How do I go about doing that?
The basics (not about callbacks, but about programming languages)
To understand callbacks first you have to understand functions. And to understand functions in javascript you first have to understand variables, values and functions.
Almost all programming language can deal with values. So if you've done any programming you'd have a basic idea of what values are (I'm going to greatly simplify types of values here and refer to both values and references/pointers as "values").
A value is a thing. For example a number or a string. So 22.31 is a value and "Hello Dave" is a value.
Most languages also have the concept of variables (not all do though). A variable is a "name" we give to values to make it easier to process values. For example, in the following, x is a variable:
var x = 12;
.. and it's value is 12.
What do variables allow us to do? It allows us to substitute a value for a name in our calculations. Just like math. For example, if x is 12 and we know we can add 1 to 12 we can also do:
x + 1
Functions are values
In javascript functions are values. For example, in the following we assign a function to a variable:
function a () {return "Hello"}
var y = a;
Since what variables do is to allow you to substitute a name for a value then if you can call the function a using the syntax a() it means you can also do this with the variable y:
y(); // returns "Hello"
Callbacks
If functions are values it also means that you can pass functions as arguments to other functions. For example, the following is how you'd normally call a function in another function:
function a () {return "Hello"}
function b () {return a() + " World"}
b(); // returns "Hello World"
If you can pass functions as a variable, it means you can do something like this:
function a () {return "Hello"}
function b () {return "Bye"}
function c (functionVariable) {return functionVariable() + " World"}
c(a); // returns "Hello World"
c(b); // returns "Bye World"
As you can see. Callbacks are not special at all. They're just the result of the fact that in javascript functions obey the same rules as other values like numbers, arrays and strings.
Callbacks does not mean asynchronous
As you can see from the example above, both calls to the function c return a value. Thus the function c is not asynchronous even though it accepts a callback. So callbacks can be used for both synchronous and asynchronous code.
A good example of a synchronous callback is the Array.sort() method. It sorts an array but accepts an optional callback for you to define how to sort (alphabetically, numerically, by last name etc.).
Why asynchronous code need callbacks
For now forget about ajax or networking code. Let's instead look at a scenario that makes it even more obvious why callbacks are used by asynchronous code.
Say for example you have a button. Now, when the user click this button you want something to happen. How do you do that?
The first thing most people do is probably something like this:
while (1) {
if (button.isClicked) {
doSomething();
}
}
OK. So that's an infinite loop that only checks if the button is clicked and nothing else. Then how do you expect the browser to update the UI and track the mouse? This leads us to the next thing people try to do:
while (1) {
if (button.isClicked) {
doSomething();
}
else {
updateUI();
}
}
OK. Great. But two problems. First, if someone were to write a library like Google Charts or jQuery or anything to do with the UI they either will write their own while(1)... loop or you must manually copy/paste their function into your while loop. This does not scale. Second and more importantly, this is inefficient. That while loop will use 100% CPU time checking a button. Wouldn't it be nicer if the browser can tell us when the button is clicked.
Fortunately in javascript functions are just values. You can pass a function to the browser and tell it to execute your function when someone clicks a button:
button.addEventListener('click', doSomething);
Note: Notice the difference between treating a function as a variable and calling a function. If you want to treat a function as a variable just use the name. If you want to call a function use braces like doSomething().
Why everyone insist on writing asynchronous functions
There are two reasons why everyone seem to insist on making asynchronous APIs, especially in languages like javascript.
First, the low-level file and network I/O are async. This means that if you want to talk to a database or a server or read a file you need to implement it as asynchronous. Also, javascript is single threaded. So if you use the synchronous versions of I/O functions you will freeze everything else.
Second, it turns out that in a lot of cases (but certainly not in all) asynchronous, single-threaded programming is as fast as or sometimes even faster than synchronous multi-threaded programming.
Combined, the two reasons above creates social pressure in the js community to ensure that all I/O code are asynchronous in order to maintain the speed advantage and not block other people's code.
If I understand correctly, you want to know more about callbacks and you want to use them. Let me try too help you using your code.
If you want to execute takeNumbersGreaterThan(5); right after insertNumbers(); using callback function, you could do something like this:
numbers = [];
greaterThan = [];
insertNumbers(takeNumbersGreaterThan, 5);
function insertNumbers(callbackFunction, callbackFunctionParam){
for (var i = 0; i<11; i++)
{
numbers.push(i)
}
callbackFunction(callbackFunctionParam);
}
function takeNumbersGreaterThan(number){
for (var m = 0; m<numbers.length; m++)
{
if (numbers[m] > number)
{
greaterThan.push(numbers[m])
}
}
}
but this is just a simple example of how you can call a callback function after some computation. This code could be improved. The point is, you can pass your callback function as parameter on your function and then later execute this callback function.
You are already there. Your code is almost completely correct.
You was just missing function keywork declaration.
The script below, shows you how to run takeNumbersGreaterThan after insertNumbers. In my sample I also changed the function sign in order to pass array as parameters and avoid some of one common "mistakes" known as closures.
var numbers = [];
var greaterThan = [];
var insertNumbers = function(numbers) {
for (var i = 0; i<11; i++)
numbers.push(i)
}
var takeNumbersGreaterThan = function(number, numbers, greaterThan){
for (var m = 0; m<numbers.length; m++) {
if (numbers[m] > number)
greaterThan.push(numbers[m]);
}
}
// run insert numbers
insertNumbers(numbers);
// run take numbers greater than
takeNumbersGreaterThan(5, numbers, greaterThan);
// log
document.write(greaterThan);
Your code dosen't use any asyncronous calls so you wouldent need to use any callbacks to handle the execution. But if you would like to know how to do it, this would be the way.
numbers = [];
greaterThan = [];
function insertNumbers(callback){
for (var i = 0; i<11; i++)
{
numbers.push(i)
}
callback(); // now execute the callback funtion
}
function takeNumbersGreaterThan(number){
for (var m = 0; m<numbers.length; m++)
{
if (numbers[m] > number)
{
greaterThan.push(numbers[m]);
}
}
console.log(greaterThan);
}
insertNumbers(function() { // here we send a functions as argument to insertNumbers which will execute when callback() is called
takeNumbersGreaterThan(5);
});
insertNumbers takes a argument called "callback". When insertNumbers is finished we simply run callback(). In the initial call to insertNumber we pass a function as argument which will be executed as soon as insertNumers finished (or callback() is called).
Code (for the most part) is executed sequentially. In the code you've provided, the computer runs though the code in the order you've provided it. First it creates a new array object and sets it to the numbers variable, then it creates a new array object and sets it to the greaterThan variable.
Then, it runs the insertNumbers function. Now what the computer does is jump to the code that you've defined in insertNumbers and executes all that code. Then, after it finishes with that, it'll return to executing the initial thread of code it was on which is back at line 4. So now it'll jump to the takeNumbersGreaterThan code. So functionally, you don't need any callbacks since your code doesn't do anything that takes an arbitrary amount of time.
That being explained, you see that takeNumbersGreaterThan doesn't get executed until after insertNumbers is executed.
The only time code isn't executed sequentially is when you start doing multi core/threaded code.
Callbacks are used when something takes an arbitrary amount of time like when you are reading data from a disk or are requesting data from the network.
Callbacks can exist, because functions defined in javascript (and many other langauges) exist as objects in the code. If you don't put the parentheses after a function name, you're actually referencing the function object just like any other variable. So you can pass that function object around in your code and to other bits of code. That is what is happening in this example.
setTimeout(myCallback, 5000)
function myCallback(){
console.log("5 seconds have passed");
}
So, as you can see, I can take my function myCallback and give it to another function, in this instance setTimeout, to use after the other function has completed a task.
I'm really new to JS and I'm having a lot of trouble writing/understanding callback functions
Let's say for example, I have the following code, but i dont want
takeNumbersGreaterThan(5);
to be executed until
insertNumbers();
is finished
numbers = [];
greaterThan = [];
insertNumbers();
takeNumbersGreaterThan(5);
insertNumbers(){
for (var i = 0; i<11; i++)
{
numbers.push(i)
}
}
takeNumbersGreaterThan(number){
for (var m = 0; m<numbers.length; m++)
{
if (numbers[m] > number)
{
greaterThan.push(numbers[m])
}
}
}
How do I go about doing that?
The basics (not about callbacks, but about programming languages)
To understand callbacks first you have to understand functions. And to understand functions in javascript you first have to understand variables, values and functions.
Almost all programming language can deal with values. So if you've done any programming you'd have a basic idea of what values are (I'm going to greatly simplify types of values here and refer to both values and references/pointers as "values").
A value is a thing. For example a number or a string. So 22.31 is a value and "Hello Dave" is a value.
Most languages also have the concept of variables (not all do though). A variable is a "name" we give to values to make it easier to process values. For example, in the following, x is a variable:
var x = 12;
.. and it's value is 12.
What do variables allow us to do? It allows us to substitute a value for a name in our calculations. Just like math. For example, if x is 12 and we know we can add 1 to 12 we can also do:
x + 1
Functions are values
In javascript functions are values. For example, in the following we assign a function to a variable:
function a () {return "Hello"}
var y = a;
Since what variables do is to allow you to substitute a name for a value then if you can call the function a using the syntax a() it means you can also do this with the variable y:
y(); // returns "Hello"
Callbacks
If functions are values it also means that you can pass functions as arguments to other functions. For example, the following is how you'd normally call a function in another function:
function a () {return "Hello"}
function b () {return a() + " World"}
b(); // returns "Hello World"
If you can pass functions as a variable, it means you can do something like this:
function a () {return "Hello"}
function b () {return "Bye"}
function c (functionVariable) {return functionVariable() + " World"}
c(a); // returns "Hello World"
c(b); // returns "Bye World"
As you can see. Callbacks are not special at all. They're just the result of the fact that in javascript functions obey the same rules as other values like numbers, arrays and strings.
Callbacks does not mean asynchronous
As you can see from the example above, both calls to the function c return a value. Thus the function c is not asynchronous even though it accepts a callback. So callbacks can be used for both synchronous and asynchronous code.
A good example of a synchronous callback is the Array.sort() method. It sorts an array but accepts an optional callback for you to define how to sort (alphabetically, numerically, by last name etc.).
Why asynchronous code need callbacks
For now forget about ajax or networking code. Let's instead look at a scenario that makes it even more obvious why callbacks are used by asynchronous code.
Say for example you have a button. Now, when the user click this button you want something to happen. How do you do that?
The first thing most people do is probably something like this:
while (1) {
if (button.isClicked) {
doSomething();
}
}
OK. So that's an infinite loop that only checks if the button is clicked and nothing else. Then how do you expect the browser to update the UI and track the mouse? This leads us to the next thing people try to do:
while (1) {
if (button.isClicked) {
doSomething();
}
else {
updateUI();
}
}
OK. Great. But two problems. First, if someone were to write a library like Google Charts or jQuery or anything to do with the UI they either will write their own while(1)... loop or you must manually copy/paste their function into your while loop. This does not scale. Second and more importantly, this is inefficient. That while loop will use 100% CPU time checking a button. Wouldn't it be nicer if the browser can tell us when the button is clicked.
Fortunately in javascript functions are just values. You can pass a function to the browser and tell it to execute your function when someone clicks a button:
button.addEventListener('click', doSomething);
Note: Notice the difference between treating a function as a variable and calling a function. If you want to treat a function as a variable just use the name. If you want to call a function use braces like doSomething().
Why everyone insist on writing asynchronous functions
There are two reasons why everyone seem to insist on making asynchronous APIs, especially in languages like javascript.
First, the low-level file and network I/O are async. This means that if you want to talk to a database or a server or read a file you need to implement it as asynchronous. Also, javascript is single threaded. So if you use the synchronous versions of I/O functions you will freeze everything else.
Second, it turns out that in a lot of cases (but certainly not in all) asynchronous, single-threaded programming is as fast as or sometimes even faster than synchronous multi-threaded programming.
Combined, the two reasons above creates social pressure in the js community to ensure that all I/O code are asynchronous in order to maintain the speed advantage and not block other people's code.
If I understand correctly, you want to know more about callbacks and you want to use them. Let me try too help you using your code.
If you want to execute takeNumbersGreaterThan(5); right after insertNumbers(); using callback function, you could do something like this:
numbers = [];
greaterThan = [];
insertNumbers(takeNumbersGreaterThan, 5);
function insertNumbers(callbackFunction, callbackFunctionParam){
for (var i = 0; i<11; i++)
{
numbers.push(i)
}
callbackFunction(callbackFunctionParam);
}
function takeNumbersGreaterThan(number){
for (var m = 0; m<numbers.length; m++)
{
if (numbers[m] > number)
{
greaterThan.push(numbers[m])
}
}
}
but this is just a simple example of how you can call a callback function after some computation. This code could be improved. The point is, you can pass your callback function as parameter on your function and then later execute this callback function.
You are already there. Your code is almost completely correct.
You was just missing function keywork declaration.
The script below, shows you how to run takeNumbersGreaterThan after insertNumbers. In my sample I also changed the function sign in order to pass array as parameters and avoid some of one common "mistakes" known as closures.
var numbers = [];
var greaterThan = [];
var insertNumbers = function(numbers) {
for (var i = 0; i<11; i++)
numbers.push(i)
}
var takeNumbersGreaterThan = function(number, numbers, greaterThan){
for (var m = 0; m<numbers.length; m++) {
if (numbers[m] > number)
greaterThan.push(numbers[m]);
}
}
// run insert numbers
insertNumbers(numbers);
// run take numbers greater than
takeNumbersGreaterThan(5, numbers, greaterThan);
// log
document.write(greaterThan);
Your code dosen't use any asyncronous calls so you wouldent need to use any callbacks to handle the execution. But if you would like to know how to do it, this would be the way.
numbers = [];
greaterThan = [];
function insertNumbers(callback){
for (var i = 0; i<11; i++)
{
numbers.push(i)
}
callback(); // now execute the callback funtion
}
function takeNumbersGreaterThan(number){
for (var m = 0; m<numbers.length; m++)
{
if (numbers[m] > number)
{
greaterThan.push(numbers[m]);
}
}
console.log(greaterThan);
}
insertNumbers(function() { // here we send a functions as argument to insertNumbers which will execute when callback() is called
takeNumbersGreaterThan(5);
});
insertNumbers takes a argument called "callback". When insertNumbers is finished we simply run callback(). In the initial call to insertNumber we pass a function as argument which will be executed as soon as insertNumers finished (or callback() is called).
Code (for the most part) is executed sequentially. In the code you've provided, the computer runs though the code in the order you've provided it. First it creates a new array object and sets it to the numbers variable, then it creates a new array object and sets it to the greaterThan variable.
Then, it runs the insertNumbers function. Now what the computer does is jump to the code that you've defined in insertNumbers and executes all that code. Then, after it finishes with that, it'll return to executing the initial thread of code it was on which is back at line 4. So now it'll jump to the takeNumbersGreaterThan code. So functionally, you don't need any callbacks since your code doesn't do anything that takes an arbitrary amount of time.
That being explained, you see that takeNumbersGreaterThan doesn't get executed until after insertNumbers is executed.
The only time code isn't executed sequentially is when you start doing multi core/threaded code.
Callbacks are used when something takes an arbitrary amount of time like when you are reading data from a disk or are requesting data from the network.
Callbacks can exist, because functions defined in javascript (and many other langauges) exist as objects in the code. If you don't put the parentheses after a function name, you're actually referencing the function object just like any other variable. So you can pass that function object around in your code and to other bits of code. That is what is happening in this example.
setTimeout(myCallback, 5000)
function myCallback(){
console.log("5 seconds have passed");
}
So, as you can see, I can take my function myCallback and give it to another function, in this instance setTimeout, to use after the other function has completed a task.
Assume the following method(Just curious, I'm hopefully fail in js)
foo(0);
function foo(i){
if(i<1000){
setTimeout(function(){foo(i+1);}, 1000);
}
alert('I am foo');
}
So if I got it true, it should alerts around 1000 I am foos after 1000 seconds.
So doesn't it bother the browser about keeping the is in a sort of big stack? it should be too much I think or I'm wrong?
Yes, you will alert 1000 "foo" messages with this code.
However, the browser will not get bothered by the amount of i variables. i is a local variable to foo and as a result, it is only kept around as long as foo is executing. Each time the setTimeout callback is finished executing, i and the entire function's footprint is eligible for garbage collection by the browser (which will happen at an opportune time).
The reason for this is that there is no preserved memory call stack here because of the use of setTimeout. setTimeout does not do anything with a returned value from foo and as a result there are no pointers in memory keeping that function nor its variable environment from being collected.
Your call stack will look like this as your code goes through it's loop:
main() [local foo]
main() -> foo [local i = 0]
main()
(empty)
setTimeout()
setTimeout() -> foo [local i = 1]
setTimeout()
(empty)
setTimeout()
setTimeout() -> foo [local i = 2]
setTimeout()
(empty)
over and over until i equals 1000.
It happens this way because setTimeout is a browser api that waits n amount of time and then inserts the callback into the callback queue. The callback will then get picked up by the event loop and executed when the callstack is empty.
So, no, you aren't in any danger of overloading the browser with stacks or vars or whatever you were worried about. Your callstack will remain small because each time foo is executed, it fires off a setTimeout and returns. the i will stay in memory until the setTimeout's callback gets executed, at which point a new i will be created within the scope created by executing foo. That new i will stay in memory until the next setTimeout executes, on and on.
Here's a video that may help explain how this works. http://www.youtube.com/watch?v=8aGhZQkoFbQ
Firstly in javascript there is no "int" you have to say var i. And it gets alone the type for the declaration. If you want get Information about stack. You can use the debug console. And navigate to the call stacks. Its a nice feature you have also a nice overview. I prefer the Chromes Debugger. You can get there with pressing F12
1000 is in a stack is not a really big size for a browser to deal with.
Moreover, there won't be more than 2 is at the same time (maybe even only one), with each function executing every second.
This code won't load 1000 calls to get triggered with an interval of 1 second, this will chain calls, preventing the stack to get bloated.
Why when calling fadeIn() onLoad does the browser run through the loop immediately. In other words there is an issue with either the setInterval or the Opacityto().
function Opacityto(elem,v){
elem.style.opacity = v/100;
elem.style.MozOpacity = v/100;
elem.style.KhtmlOpacity = v/100;
elem.style.filter=" alpha(opacity ="+v+")";}
function fadeIn(){
elem=document.getElementById('nav');
for (i=0;i==100;i++){
setInterval(Opacityto(elem,i),100);}
}
I think someone will tell me this can be done easiest with jQuery but I'm interested in doing it with javascript.
Thanks!HelP!
You've got several problems with your fadeIn() function:
A. Your for loop condition is i==100, which is not true on the first iteration and thus the body of the for loop will never be executed (the i++ won't ever happen). Perhaps you meant i<=100 or i<100 (depending on whether you want the loop to run 101 or 100 times)?
B. Your setInterval code has a syntax error EDIT: since you've updated your question to remove the quotes - setInterval expects either a string or a function reference/expression. So you need to either pass it the name of a function without parentheses and parameters, or a function expression like the anonymous function expression you can see in my code down below. in the way you try to build the string you are passing it. You've got this:
"Opacityto("+elem,i+")"
but you need this:
"Opacityto(elem," + i + ")"
The latter produces a string that, depending on i, looks like "Opacityto(elem,0)", i.e., it produces a valid piece of JavaScript that will call the Opacityto() function.
C. You probably want setTimeout() rather than setInterval(), because setInterval() will run your Opacityto() function every 100ms forever, while setTimeout() will run Opacityto() exactly once after the 100ms delay. Given that you are calling it in a loop I'm sure you don't really want to call setInterval() 100 times to cause your function Opacityto() to be run 100 times every 100ms forever.
D. Even fixing all of the above, your basic structure will not do what you want. When you call setInterval() or setTimeout() it does not pause execution of the current block of code. So the entire for loop will run and create all of your intervals/timeouts at once, and then when the 100ms is up they'll all be triggered more or less at once. If your intention is to gradually change the opacity with each change happening every 100ms then you need the following code (or some variation thereon):
function fadeIn(i){
// if called with no i parameter value initialise i
if (typeof i === "undefined") {
i = -1;
}
if (++i <= 100) {
Opacityto(document.getElementById('nav'), i);
setTimeout(function() { fadeIn(i); }, 100);
}
}
// kick it off:
fadeIn();
What the above does is defines fadeIn() and then calls it passing no parameter. The function checks if i is undefined and if so sets it to -1 (which is what happens if you call it without passing a parameter). Then it increments i and checks if the result is less than or equal to 100 and if so calls Opacityto() passing a reference to the element and i. Then it uses setTimeout() to call itself in 100ms time, passing the current i through. Because the setTimeout() is inside the if test, once i gets big enough the function stops setting timeouts and the whole process ends.
There are several other ways you could implement this, but that's just the first that happened as I started typing...
My guess is that there is a nasty comma inside the setInterval, messing the argument list:
"Opacityto("+elem,i+")"
^^^
here
You could try quoting the comma
+ "," +
but eval is evil so don't do that. The good way is to pass a real callback function:
function make_opacity_setter(elem, i){
return function(){
OpacityTo(elem, i);
};
}
...
setTimeout( make_opacity_setter(elem, i), 1000);
Do note that the intermediate function-making-function is needed to avoid the nasty interaction between closures and for-loops.
BTW, when you do
setInterval(func(), 1000)
you call func once yourself and then pass its return value to setInterval. since setInterval receives a junk value instead of a callback it won't work as you want to.
How does setInterval handle callback functions that take longer than the desired interval?
I've read that the callback may receive the number of milliseconds late as its first argument, but I was unable to find why it would be late (jitter, or long running functions).
And the wonderful follow up, does it behave differently for the common browsers?
Let me quote an excellent article about timers by John Resig:
setTimeout(function(){
/* Some long block of code... */
setTimeout(arguments.callee, 10);
}, 10);
setInterval(function(){
/* Some long block of code... */
}, 10);
These two pieces of code may appear to
be functionally equivalent, at first
glance, but they are not. Notably the
setTimeout code will always have at
least a 10ms delay after the previous
callback execution (it may end up
being more, but never less) whereas
the setInterval will attempt to
execute a callback every 10ms
regardless of when the last callback
was executed.
Intervals may execute back-to-back with no delay if they take long enough to execute (longer than the specified delay).