There are several solutions to this problem. One approach that has worked well with scripting languages in the past is JIT (Just-in-Time) compilation. Here, code is compiled to native machine code as needed. This approach only works well with routines that are called over and over. If you're calling a routine just once-one that doesn't have many for loops-it's often faster to just interpret it rather than first compile it and then run it. The compilation can take longer than just running the interpreted form. But if you have a routine that's called over and over, compiling it the first time and then running the compiled form can make a big difference.
If you've programmed in C++, you're well aware that before you can access a class, you need to have the class fully defined. Typically you'll put your class definition in a header file. This definition includes the word "class," the name of the class, and a list of all the member variables and member functions. Later in your code you can create objects that are instances of the class.
The class is much like a cookie cutter for objects. Once the program is running and you create an object, the object has the members it will have until it is destroyed. You can change the value of the members (such as changing the height member of a Rectangle object from 10 to 20 or changing the balance member of the CheckingAccount object from 100 to 100,000,000) but you can't add or remove members. While your program is running, you can't add a depth member to your Rectangle class. The only way you can make changes is by changing the code and recompiling. But then when you run the program, all your Rectangle objects will have the new member.
In fact, although it's not necessarily the best programming practice, you can even provide the user of your program with a text box where he or she can type in a name, and then you can add a member to an object by that name. Thus, your user could suggest the name eWEEK for a member, and you could add that member to the object and give it a value.
And further, that value can be any type you want-again something totally different from C++. In C++, if you have a Rectangle class with members Height and Width and you specify that they are to hold integers, then you can't store a string in one of these members while the program is running. In fact, the compiler will catch it and stop you while you're compiling before you're even able to run the program.
Googles Solution: Hidden Classes
Hidden Classes in V8
Google drew on its team members' expertise with earlier compiled, dynamic languages, such as an experimental language called Self (created when the team members worked at Sun Microsystems). To a programmer like myself, the concept at first sounds horrible. When I first read about it I was shocked that they would do something so seemingly inefficient. But in fact, it works beautifully.
During this time, your object went through three stages: First it had no members, then it had only one member, then it had two members.
While compiling the code, V8 will create in the background a compiled class (just like you have in C++ at run-time) that contains no members. Then as the compiler discovers the line of code that adds a Width member, the compiler will create a second class, this one with the Width member. Then as the compiler encounters the next line, it will create a third class, this one with the Width and Height members.
That's right, it creates three classes. But the compiler is smart, because later on in your code, when you create several instances of your Rectangle class, the compiler will know to use the third class.
Of course, that's sort of a simple example. In fact, you might add the eWEEK member to one of your objects outside of the constructor. In that case, the compiler will create a fourth class, this one including the eWEEK member.
In other words, you might have multiple instances of Rectangle, and behind the scenes several of them may share the third class, while others might have their own separate class. These are called hidden classes.
Taking Out the Garbage
Collecting the Garbage
If not, here's how it works: Suppose I create a Rectangle object. I use that in a calculation. Then I'm done with the object. In a language like C++, you write a line of code that tells the run-time library that you're done with the object. The run-time library will then delete the object and allow the part of memory where the object was stored to be used again for other objects.
But the problem is the object might get saved away as a member within yet another object. Then the run-time can't delete the first object until this other object is no longer needed! Can you say, big mess? Yes, there is more than one reason it's called "garbage collection," and I'm sure some people would like to include other choice words instead of garbage, as well as directives about other people cleaning up their own, uh, messes.
Garbage collection is always a problem with languages, because often the actual garbage collector (the code that does the cleaning) only runs occasionally, and when it does, the program slows waaaaaaay down.
Google describes in its developer documentation a sophisticated garbage collector that Chrome uses. This collector stops everything and does its job very quickly while only collecting what's necessary, and then allowing everything else to resume. Personally, that sounds suspicious to me; however, I can understand how that could be better than having the garbage collector slowly churn away for minutes on end while you're continuing to do your work, albeit slowly, due to the garbage collector slowing everything down-and, with the work you're doing slowing the garbage collector down, causing it to run even longer. So perhaps this new method is better.
I have a couple of Web sites I use regularly, including one for checking my personal e-mail via a Web interface. This particular interface is really nice, but it's always been horribly slow. For that reason, I only use it when necessary.
I tried it using Chrome and was impressed. The first time the Compose box opened, it was a little sluggish as all those formatting buttons slowly drew. But the next time I ran it, it opened instantly, and definitely felt like I was using a desktop (in other words, non-Web) application. Now this, of course, is just anecdotal and not a benchmark test. But it was fast.
But is Chrome's V8 faster than the latest development build of Firefox? And is it faster than anything Microsoft might secretly be doing? (I'm bettin' that Microsoft is working on its own native compilers, although I don't know for sure.)
So far, the jury is out. I've seen pages "proving" through benchmarks that V8 is faster than Firefox's new engine. But I've also seen pages "proving" that Firefox's engine is faster. It's hard to say. One thing is for sure: They're both fast, and they both fly. And that's great news for us developers, and even better news for the users across the planet fighting with these slow Web 2.0 applications.
Jeff Cogswell is the author of Designing Highly Useable Software. Currently Jeff is a senior editor with Ziff Davis Enterprise. Prior to joining Ziff, he spent about 15 years as a software engineer, working on Windows and Unix systems, mastering C++, PHP, and ASP.NET development. He has written over a dozen books.