Experiments with JavaScript

Experiment, test, analyze. Experiment again, test again, analyze again. This is the process of learning the environment, the language and the tools I work with. Taking things apart, looking inside, diving deeper and building a picture of understanding. I think JS is a language with a lot of hidden corners and this time I’ve decided to dig into timers and intervals of the JavaScript. This experiment grew into a browser-based activity monitor of JavaScript execution and I would like to share my experience about it, with you.

How it all started

As you all know, timers in JavaScript get triggered at the moment when the browser is idling. This is described very well in one of the John’s articles at http://ejohn.org/blog/how-javascript-timers-work/ : “Since all JavaScript in a browser executes on a single thread asynchronous events (such as mouse clicks and timers) are only run when there’s been an opening in the execution.”

This information gave me a pretty absurd idea: Is it possible to determine the active/idle state of the browser by using the “opening” behavior of the timers? I thought – yes. But the question is – how? If we start looping “setTimeout” with scheduled time of zero milliseconds, we could collect an interval between the timers and identify the current browser’s state ( active/idling ) based on the interval’s info. Something, like the picture below shows:

To prove for myself that this craziness had at least a small rational kernel, I built a small prototype. I injected it into a heavy ajax-based application and I was quite happy with the results. All the results I received had a common pattern in them, indicating that the calculated interval is a reliable source for tracking the browser’s activity. I do agree, that maybe this approach can’t be used for precise profiling of an application, but I still think that it could be used to get the global picture of the browser’s execution flow for the ajax driven applications.

Path into the experiment

To quickly proceed with this experiment, I started with pretty simple code. Collect the difference between the current time and time of the previous timer call, save all the values into an array, and I have everything I need for now. In the first place the code looked like this:

function start(){
    var timer_start = (+new Date()),
          timer_end,
          stack = [];
    
    (function collect() {
        timer_end = (+new Date());
        stack.push( timer_end - timer_start );
        timer_start = timer_end;
        setTimeout( collect, 0 );
    })();

    return stack;
}

// Example of the stack array
// [ 10, 11, 10, 11, 10, 11, 14, 19, 17, 16, 15, 
//    15, 13, 13, 13, 12, 17, 13, 10, 10, 11, 10, 
//    11, 10, 11, ...]

In all the tests I’ve done so far, there was one thing bothering me. Even when the browser was idling, there were almost no zero values in an array, but two digits were continuously repeating. For example: in Firefox (mac) these were 10 and 11. You can see that also also in the example above.

It was clear to me that these two values represent a kind of “baseline” for browser’s idling state. In Mozilla Developer Network (MDN) it’s described as a timeout clamping https://developer.mozilla.org/en/DOM/window.setTimeout ( at the bottom of the page ). Summarizing: clamping is the minimum amount of time between any interval or timer. I also tested different browsers in diferent OS’s ( Windows, Linux, OSX ) and almost none of them got zero values at the moment of idling. Besides that, these clamping values varied between all the browsers.

The funny thing about the timers clamping is that this interval is not just one static number, but two numbers, repeating in turn. These two numbers I called the “baseline”. Let’s look at some of them in different browsers.

Table: the baseline for different browsers

Despite the fact that the MDN claims that there is always a delay between timers, this was not the case. Sometimes the interval values were lower than the clamping interval, even dropping to zero value. Digging deeper sheds some light on this weired behavior. I’ve discovered that the dropped interval happened only at the moments of non idle state, when the browser was busy with really heavy execution flow. This gave me an idea that the timers are executing in two different cases.

Case one: The browser is idling. It periodically checks for the suitable timer/interval inside the timer’s and interval’s queue. This period is exactly the clamping moment, which is described in the MDN. At the moment when the browser finds an interval or a timer to be executed – fire.

Case two: Browser is executing JS code. Periodic checks are stopped to prevent timers and intervals being executed at the moment of other code execution. This means, the browser is waiting for an “opening” now. When the execution is finished, the browser starts checking the timers’ queue, without waiting for clamping offset. It controls if the execution of the timer was not far away in the past/future from the current moment and if not the browser executes it. This case also explains why my prototype code gave as a first value – zero. Because there was nothing else to execute and browser could pick up the scheduled timeout.

I do not claim, that this is actually what is happening, but by analyzing from the outside, it appeared to me so.

Tests with simple dump tool

Well, enough of raw data. Users need a GUI and I also needed some representation of the collected data. For this reason I made a first prototype version of a dumping tool. As an input it receives the array with values and as an output it produces some “very” simple graph like the one bellow.

This graph has two sates: “activity” and “no activity” state. They are represented by high level and low level of the bar, respectively. As you’ve noticed the high bar consists of red and black areas. In this way duration and type of the activity was represented.

Let’s start with the red part. The longer the red bar is, the longer the browser stays active. It becomes red, only when the activity interval is longer than the “baseline”. At the moment when the activity goes below the baseline, it becomes a small black stripe.

Because of the visual graph, you can analyze data much faster than with the raw array. Faster analysis, more intensive tests. More conclusions. And the first conclusion which I made was that, it is almost impossible to trace activity, if it is less than the clumping interval. But still, here comes the nice part, web pages nowadays are all heavily event driven, and even a small event often executes longer than the clumping interval. Take for example a typing event, resizing a window, etc. Typing event in an text-area triggered this so well, that I could easily see this in the graph.

Image : Firefox Typing activity

Image : Chrome Typing activity

Or, scrolling. I scrolled a couple of times and I think, this is quite fascinating to see, that graph shows you this four scrolls I made.

Image : Safari scroll activity

Last activity as an example is based on resizing of the Firefox window:

Image : Firefox resize activity

Another conclusion I made was that based on the examples you can see that the timers depend not only on the JavaScript execution of the code, but also on the internal parts of the browser, like moving of the window, or opening a new tab. So, keep this in mind

Besides all the graphs of event driven behavior, I also came across another interesting aspect in Firefox when it was “doing nothing” and checking the idle state. Firefox when idling still has some activity peeks. I also looked at Chrome and Safari, but they are all stable as statues. These browsers showed no sign of activity at all, in idle state. First, I thought that it’s just some crazy late running timer, but when I checked the Activity Monitor of OSX I found that there are also the same small peaks of the CPU usage for Firefox processor.

Image : Firefox small idle peaks

From here, I can draw two conclusions: 1. Firefox is really doing something all the time (which is reflected in the CPU usage) or 2. Firefox just has inaccurate timers.

More ?

I could not resist and not to build some kind of runtime activity monitor.

First thing which I did was to check the response of this monitor to the activity. The fastest way was to fire up native Activity Monitor of OSX and compare the peaks of both. It was a surprise to see peaks in the browser monitor first, and only after that in OSX.

Image : Firefox and Activity Monitor

Because runtime monitor gives you a global overview of the activity, it was really nice to play with it in a different browsers and compare how they react on different kinds of events/execution. It gave me an instant coverage of the places where browsers spend much time and of the places where they “fly”. For example, I used the test code like this

var arr = [];
for (var i=0;i<16099;i++) {
    var div = document.createElement("div");
    arr.push( div );
}

and I got these results :

Images: Execution of test code : Firefox (win), IE (win), Chrome(win)

Another thing which I noted is the way IE behaves. Its activity always stays at "zero" level when it's idle, a really "silent" browser. Also in the image above you can see that IE gave only the activity of the JS execution, but nothing else. I assume that it has to do with the clamping interval. It has the highest interval between all the browsers, which means that the activity bellow 15ms will always stays invisible to us. Sad. At least we can track resize of the window, with ease

Image: Resizing IE

The source of it you can find source at github.

Epilogue

While I was busy with timers I found another interesting article about timers and intervals. I did a small experiment with that too and it appeared that the argument which Firefox passes to the timeout function is equal to the sum of the calculated interval + the baseline. It's not always the same, but in most situations it is. I did not perform any further tests in other browsers, but if you are interested feel free to fill this gap.

This experiment gave me some interesting thoughts. This monitor can actually help you to look at the application from a different angle. It can show you the way the application performs and interacts with the browser. It can show you that the clicking on a button in one browser triggers a more complicated wave of the execution than in the other browsers. It helps to see you your web application as a whole piece and not as a bunch of separated code regions.

As usually, a playground is available for everyone who is interested in it :

http://nemisj.com/src/amonjs/

Known issues: In Linux in Firefox calibration of the baseline sometimes is not working the first time, so you should recalibrate if it behaves strangely.

Summary : Do you still believe that there are only public, private and privileged members in JavaScript objects? With JavaScript, you never can be sure.

Lego principle

As I might have told you, I think that JavaScript is an amazing language. Even so, I would like to repeat it again. It is the ultimate language for me, and I hope it’s so for you. JavaScript is like a Lego constructor, depending on how you combine different parts, you might get a car, a house or maybe just a pile of crap. Your imagination defines the rules.

This time I’ve discovered some unbelievable combination. It allows you to create and use so called “protected” members in JavaScript. How do I define protected members in JavaScript? As a mixture of both, private and public members, which gives you the possibility to inherit, override and access private members without use of a privileged bridge. If you don’t know what these members are or have just forgotten them, here is a link to refresh your memory. For now, let’s look at an example below :

function Some(...) {
    // defining private member
    var value = 'value';
}

Some.prototype.getValue = function() {
    return value;
};

Code : Scoping issue when adding methods to prototype

As you might have noticed, the code above is broken. Executing getValue function, will throw an exception, because the declaration of getValue is not in the same scope where value variable is declared. To make the code work, function getValue should be declared inside a constructor, hereby becoming a privileged member. This limitation makes it impossible to access the private variables outside the constructor.

The experiment I wrote does allow you to work with the private members outside the constructor, meaning you can add functions to the prototype and expect them to behave as if they are all in the same scope. Sounds cool, right? Actually, it doesn’t look half bad.

Some = Declare({
    _value : 'value',
    getValue : function() {
        return _value;    
    }
});

SubSome = Declare( Some, {
    setValue : function(val){
        _value = val;
    }
});

Code : Declaring class with protected member using prodec wrapper

In the example above there is one protected member _value. It is declared like other public members getValue and setValue, but it is accessed as a private member. Accessing _value variable in the SubSome class shows that the private scope, indeed, “can be” shared. I would like to put extra emphasis on the fact that the protected member is not accessible from outside the object, there is just NO possibility to do that. This means that someObj._value will be unavailable.

I used a declaration wrapper to hide all implementation details ( I love code separation ), but here is the approximately unwrapped code, which will help you to easily “diff” both listings:

Some = Declare();

Some.prototype = {
    _value    : 'value',
    getValue : function() {
        return _value;
    }
}

//Adding inheritance
SubSome = Declare();
SubSome.prototype.__proto__ = Some.prototype; // Note: IE does not support __proto__ convenience
SubSome.prototype.setValue = function(val) {
    _value = val;
}

Code : Declaring protected members with prototype

The code above does the same thing as the first broken example, except that it also consists of SubSome inheritance. The SubSome inheritance is there to show you that you can access protected members declared in a superclass. Consider that the constructor is created by the Declare function and not like usually by function(){}. ( For those who need explanation about __proto__- here is link ) Note, that it’s also possible to share protected functions, not only variables, like in this example.

Internals

I guess you already have plenty of questions concerning the implementation of this experiment. I will not withhold the answers from you and will start explaining all the details right now. If you think that the code is the best source for explanation, I suggest you move at once to the last part of this article or visit a playground.

The first answer is with . I was always wondering how private scope could be shared. We have the ability to share “this” scope, by saving it as variable, but we have no way to save a private scope and unroll it somewhere else. In context of “protected” members, we really need to save the private scope and apply it in different places. Even though we can’t do that “officially”, it’s possible to emulate this behavior by using with keyword. I’m sure everyone of you know what with is doing, but everyone is avoiding it, because it’s a bad coding practice. Anyhow, let’s leave prejudice out of this and look at the possibilities with brings us.

var obj = { zork : "Bork" }
with (obj) {
    alert( zork );
}

Code : “With” Nature

This code, is doing exactly what is needed for emulating protected members. It allows you to access obj variables as if they are private variables. Looking from with perspective, the given obj can be seen as private scope. But let’s leave this part for a second and look at the next code.

var s = function(){
    var zork = 'Bork';
    return function() {
        alert( zork );
    }();
}
var fnc = s();
fnc(); // alerts Bork

*Code : Closure nature *

We know that internal closure bla will popup “Bork”, because of the nature of the closures. Now, I will combine both characteristics of closure and with and show what would happen if we create closure inside with. All the variables of obj will be available to the closure, meaning we could manipulate the scope :

var s = function(){
    var obj = { zork : "Bork" }
    with (obj) {
        return function() {
            alert( zork );
        }();
    }
}

var fnc = s();
fnc(); // alerts Bork;

Code : Combining “closure” with “with”

The result is the same, except now, we have our private scope coming from object and not from “var” declaration. This is really the main element of my experiment : Creation of the functions inside with and assigning them to the object. All thanks to the dynamic ability of JavaScript, which allows us to create and bind functions at runtime. Time to see how to apply this closure-with combination to create objects based on their prototype.

We know, that every constructor consists of a prototype object. This object contains almost the full definition of the object. I say almost, because functions can be created inside the constructor, which are not visible through the prototype. Even then, during object creation, it’s possible to walk through the prototype of the object and do things based on some requirements. For example : As you’ve already seen, protected members in my code start with an underscore. Based on this, we can collect all such members and place them inside our protected object. Later we can use this object inside with, so that the underscore members appear as private members.

function Some() {
    var proto = Some.prototype;

    this._protected = {};

    for (var i in proto) {
        if ( /^_/.test(i)) {
            this._protected[i] = proto[i];
        }
    }
}

Code : Creating protected scope object

Scope is built, it’s time to use it :

Some.prototype._value    = 'value';
Some.prototype.getValue = function() {
    with (this._protected) {
        alert( _value );
    }
}

Code : Using protected object to emulate private scope

As you can see, we’ve made the first, yet the most important step of the “protected members” principle. However, there are still a number of issues. To start with, protected scope is available to the outside world, because it’s publicly defined. Further more, it is the requirement for the with keyword in every function where protected scope is presented. These issues leave an implementation footprint in the declaration of the class, which does not look very neat. Both issues are related, meaning that fixing them should be done at the same time.

First of all, we need the technique to hide our protected scope from the public “eyes”. A solution to this would be to use the nature of private members. The protected scope object should be defined as a private member. The only issue in this case that we will be facing the problem described above, namely inability to access private members outside the constructor. A fix for that would be to keep creation of the functions inside the constructor as well. The question is, how? Well, in the constructor we have access to any function and to the object itself, so if we could clone every function of Some object and reassign it, the desired behavior would be achieved.

To clone a function I have to resort to using another “evil” keyword – eval. Because every function exposes its body via toString(), we could evaluate it, at the places we need. Here is clone example :

var fnc = function() { alert('a') ; }
var member = '';
var clone;
clone = eval( "clone = " + fnc.toString() );

Code : Cloning function

Because eval remembers the scope in which it was evaluated ( has access to the member variable), a function can be cloned inside the with statement, having access to the protected scope object. Well, enough talk, it’s time to put all the building blocks together and see the result :

function Some() {
    var proto = Some.prototype;

    var protscope = {};

    for (var i in proto) {
        var member = proto[i];
        if (typeof member == "function") {
            with (protscope) { //adding protected scope 
                // cloning, 
                // cloned function receives automatically the scope correct scope
                member = eval( "member = " + member.toString() );
            }
        }
         
        // doing reassign
        this[i] = member;
        
        if ( /^_/.test(i)) {
            protscope[i] = proto[i];
            // removing protected variables from outside
            this[i] = null;
        }
    }
}

Some.prototype._value = 'value';
Some.prototype.getValue = function() {
    alert( _value );
}
Some.prototype.setValue = function(val) {
    _value = val;
}

Code : Result of all the effort – creating protected members

If you are familiar with JavaScript the code should be fairly self explanatory. To get a better feeling for protected members, as I mentioned earlier,I’ve created a playground for you. I did not cover all parts of the declaration wrapper here, such as dealing with this keyword, using super classes, etc. If you are interested, grab the source code and enjoy.

How much does it cost ?

What actually is a price of protected members? First of all – Speed. I haven’t performed any benchmarks, but by analyzing the code I can tell you that this emulation will run slower than normal creation of objects. Using with together with eval for every object member will stall the runtime. Secondly – memory consumption. Using a set of functions for every instance will eat up more memory in comparison to the prototype based instances.

Nevertheless, if the speed does not play a big role and you see advantages in using protected members you could adopt the code for your own needs.

“Everything old is new again”

Info: I’ve posted this quiz almost two years ago. Unfortunately I’ve got some problems with host and this quiz was not available anymore. I still like this challenge, that’s why I decided to repost it again.

Introduction

I always enjoy programming JavaScript, it always brings me some new and interesting puzzles. I was explaining functions in JS to a friend and got realized that it’s a really great language with its flexibility, closures, anonymous functions, first-class functions etc. Even the stupid idea that you can write a function by calling it an unlimited number of times is simply amazing.

Example:

fnc()()()()()()()()();

Challenge

Further thinking gave me the idea that it would be nice to have this function do something more weird and confusing. This useless function should give as the output the number of times it has been called (for example in alert box). The challenge of this puzzle is that it must give output only at the end of the execution, with the last call.

That means that code like that fnc()()()()()()() MUST show one alert box with text “Fnc called 7 times”.

After some experiments I found a solution for this puzzle and I figured that you might also want to challenge yourself by finding out the way it can be done. So, I propose everyone to post their solutions in the comments.

Solution

Try it live :

(Execute)

If you decided that it’s enough for you to break your head with this puzzle, you can always check my solution (in code ).

I hope you liked my idea, and also get enthusiastic, like I did, when I was searching for the answer.

The original entry was posted on Saturday, July 12th, 2008 at 4:12 pm