将Javascript代码封装在对象中是否会影响性能？

Question

I am wondering if it is more or less efficient to encapsulate the main body of your JavaScript code in an object? This way the entire scope of your program would be separated from other scopes like window.

For example, if I had the following code in a JavaScript file:

/* My main code body. */
var somevar1=undefined;
var somevar2=undefined;
var somevarN=undefined;

function somefunction(){};

function initialize(){/* Initializes the program. */};
/* End main code body. */

I could instead encapsulate the main code body in an object:

/* Encapsulating object. */
var application={};
application.somevar1=undefined;
application.somevar2=undefined;
application.somevarN=undefined;

application.somefunction=function(){};

application.initialize=function(){/* Initializes the program. */};

My logic is that since JavaScript searches through all variables in a scope until the right one is found, keeping application specific functions and variables in their own scope would increase efficiency, especially if there were a lot of functions and variables.

My only concern is that this is bad practice or that maybe this would increase the lookup time of variables and functions inside the new "application" scope. If this is bad practice or completely useless, please let me know! Thank you!

Answer 1

I've no idea what the performance implications are (I suspect they're negligible either way, but if you're really concerned, test it), but it's very common practice in JavaScript to keep chunks of code in their own scope, rather than having everything in the global scope.

The main benefit is reducing the risk of accidentally overwriting variables in the global scope, and making naming easier (ie you have window.application.initialize instead of eg window.initialize_application ).

Instead of your implementation above, you can use self-calling functions to create an area of scope just for one bit of code. This is known as the module pattern .

This has the added advantage of allowing you to create “private” variables that are only accessible within the module, and so aren't accessible from other code running in the same global object:

/* Encapsulating object. */
var application=( function () {
    var someprivatevar = null// This can't be accessed by code running outside of this function
      , someprivatefunction = function () { someprivatevar = someprivatevar || new Date(); };

    return {
        somevar1: undefined
      , somevar2: undefined
      , somevarN: undefined
      , somefunction: function(){}
      , getInitialized: function () { return someprivatevar; }
      , initialize: function (){/* Initializes the program. */ someprivatefunction(); }
    };

})();

application.initialize();
application.getInitialized();// Will always tell you when application was initialized

Answer 2

I realize you asked a yes or no question. However, my answer is don't worry about it, and to back that up, I want to post a quote from Eloquent Javascript , by Marijn Haverbeke.

The dilemma of speed versus elegance is an interesting one. You can see it as a kind of continuum between human-friendliness and machine-friendliness. Almost any program can be made faster by making it bigger and more convoluted. The programmer must decide on an appropriate balance.... The basic rule, which has been repeated by many programmers and with which I wholeheartedly agree, is to not worry about efficiency until you know for sure that the program is too slow. If it is, find out which parts are taking up the most time, and start exchanging elegance for efficiency in those parts.

Answer 3

Having easy to read code is key to my issue here, so I'm going to stick with the modular approach even if there is a slightly longer lookup chain for variables and functions. Either method seems to have pros and cons as it is.

On the one hand, you have the global scope which holds several variables from the start. If you put all of your code right in the global scope, your list of variables in that scope will include your own as well as variables like innerWidth and innerHeight. The list to search through when referencing variables will be longer, but I believe this is such a small amount of overhead it is ridiculous to worry about.

On the other hand, you can add just one object to the global scope which holds all of the variables you want to work with. From inside this scope, you can reference these variables easily and avoid searching through global variables like innerWidth and innerHeight. The con is that when accessing your encapsulated variables from the global scope you would have a longer lookup chain such as: globalscope.customscope.myvar instead of globalscope.myvar or just myvar.

When I look at it this way, it seems like a very trivial question. Perhaps the best way to go about it is to just encapsulate things that go together just for the sake of decluttering code and keep focus on readability rather than having a mess of unreadable code that is only slightly more efficient.