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 another language.
Like language acts like I showed you with a compiler.
There's no compilation step before you can start running your code.
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 in 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 would 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 another 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 it sees code like this that we just loop over
and it has the same inputs returning the same outputs,
well, it can actually just simplify 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?
Well,
they both have their pros and cons.
Compiler obviously 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 browsers started doing.
Browsers started mixing compilers
specifically these git compilers for just in time
compilation to make the engines faster.
So let's see how 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.
There's 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 in the V8 engine is called Ignition
and it takes this ESD and it spits out bytecode.
And 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 code, 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 or just 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 the code and compiles it or modifies it.
So it does what you ask it do, 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 mixes and matches things and it constantly runs through this loop.
And this means that the execution speed of JavaScript
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.
JIT 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 it to jet 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 isn't perfect.
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 D optimization, which takes even longer
time to reverted back to the interpreter.
So by learning this, we're going to have a video coming up
where we learn how to write optimized 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.