Welcome back.
Let's have a look at the pros and cons of each.
First off, interpreters are quick to get up and running, right?
Because if we go to our example.
With an interpreter, we don't have to convert this into a another language like language.
Acts like I showed you with a compiler.
There's no compilation step before you can start running your coat.
You just give this to an interpreter and the interpreter starts translating their first line and just
runs the code for us.
Because of this, an interpreter is a natural fit for something like JavaScript.
Right.
A JavaScript file gets sent from the server to the browser to the client on the front end.
And we want that JavaScript to execute right away because our users are going to be waiting on the Web
page trying to interact with our application.
And JavaScript originally was created for the browser.
So being able to interpret JavaScript and run it as fast as possible.
Well, that was ideal.
And this is exactly why JavaScript used interpreters at the beginning.
But there's a con with using an interpreter.
And this is the same problem that Google had back in the day when they had Google Maps running a lot
of JavaScript.
But it'll get slower and slower and slower because the problem with interpreters is that when you're
running the same code more than once.
For example, if you're in a loop like this one over here where we're running this piece of code over
and over and over, even though it gives us the same result.
It can get really, really slow.
The compiler actually helps us here.
It takes a little bit more time to start up because it has to go through that compilation step at the
beginning, go through our code, understand it and spit it out into a nother language.
But the compiler will be smart enough that when it sees code like this, and this is obviously a simplified
version of it, but if he sees code like this that we just loop over and it has the same inputs returning
the same outputs.
Well, it can actually just simplified this code.
And instead of calling this function multiple times, can just replace this function with something
like nine because we know that we want to return not.
Because a compiler doesn't need to repeat the translation for each pass through in that loop, the code
generated from it is actually faster.
And these sort of edits that compilers do are called optimizations.
So let's go back to that question.
Interpreter or a compiler?
Which one is better?
They both have their pros and cons compiler, obviously, it takes a little bit longer to get up and
running.
But the code is going to eventually run faster or interpreter that is really fast to get up and running,
but unfortunately doesn't do any optimizations.
Is there a way that we can get the best of both worlds?
And this is what some engineers came up with in late 2000.
And if we use Google as our example with the V8 engine, what if we combine the best of both worlds?
What if instead of using the compiler and interpreter, we combine these two?
And create something called a jet compiler or just in time compiler.
And this is exactly what browser started doing, browsers started mixing compilers, specifically these
JIT compilers for Just in Time compilation to make the engines faster.
So let's see how it V8 engine does this underneath the hood in order to use the best of both worlds.
Remember, we passed the code.
We turn it into an abstract syntax tree.
And then this code initially goes to an interpreter.
And by the way, again, I'm showing you what the V8 engine does.
They're small changes in different engines.
But this is probably the best, most optimum way to run the JavaScript engine.
As I'm recording this video.
Initially, the code gets sent to the interpreter.
And in the V8 engine, this is called ignition.
I know they have really cool sounding names to make them sound like they do things fast.
But this interpreter and the V8 engine is called ignition and it takes this SSD and it spits out bytecode.
I remember bytecode is code that's not as low level as machine code, but it's code that is able to
be interpreted by the JavaScript engine in order to run our programs.
So that's the first step.
But then we see over here that there's something called a profiler.
This old man that's checking out our code in this profiler also called a monitor, monitors and watches
our code as it runs.
And makes notes on how we can optimize this coat.
Such as how many times it is being run, what types are used and how we can possibly optimize this.
And using this profiler as the code is running through our interpreter, which tells our browser what
to do.
If the same lines of code are run a few times.
We actually pass off some of this code to the compiler or a git compiler, adjust in time compiler,
because as the code is running.
The interpreter is going to say, hey, here's some code for you to optimize, passes it off to the
compiler and the compiler as the application is running, takes a code and compiles it or modifies it.
So it does what you ask it to, but trying to make optimizations.
So it runs faster.
And it then replaces the sections where it could be improved of the bytecode with optimized machine
code.
So that code, that optimized code is used from that point on instead of the slower bytecode, so it
makes it matches things and it constantly runs through this loop.
And this means that the execution speed of jobs script code will be improving.
Right.
This means that the execution speed of the JavaScript code that we entered into the engine is going
to gradually improve.
Right.
Because the profiler and the compiler are constantly making updates and changes to our bytecode in order
to be as efficient as possible.
So interpreter allows us to run the code right away, and the compiler and profiler allows us to optimize
this code as we're running.
That's where the name comes from.
Git compiler.
Just in time, compiler.
And this compiler for V8 is called Turbo Fan.
Again, a cool sounding name to make it sound like things are going fast.
And by the way, just a bit of a fun fact.
Previous versions of V8 Engine actually used to JIT compilers with really cool sounding names, but
they changed it to this method because there are some faster optimizations that they could do.
So why do we just learn all of this?
You can write JavaScript without knowing any of this stuff and you'll be fine.
Now that we know how the engine works underneath the hood, we can write more optimized code code that
the compiler can take and run it faster than our regular JavaScript.
And we also can use this knowledge to make sure that we don't confuse the compiler because the compiler
is imperfect.
It can make mistakes and it can try to optimize code that actually does the opposite.
And if it makes a mistake and it does something unexpected, it does something called the optimization,
which takes even longer time to reverted back to the interpreter.
So by learning this, we're gonna have a video coming up where we learn how to write optimize code so
that we help out this profiler and compiler to make sure that we're able to run the fastest code possible.
And let's learn those optimizations.
But first, let's talk about something quickly.
I'll see in the next video by.