►
Description
Discussion for Chapter 2: Compilation of the book Ruby Under a Microscope.
A
D
B
D
E
E
A
D
Yeah,
I
noticed
that
too,
that
optional
arguments
and
keyword
arguments
both
had
looked
like
extra
overhead,
where
it
had
to
look
stuff
up,
but
yeah
not
sure,
like.
I
think
they
talked
about
that
a
little
bit
in
the
earlier
group,
which
was
actually
last
week
just
like
whether
or
not
it
would
make
sense
to
do
some
sort
of
cache
of
the
sort
of
byte
code
that
it
writes.
D
So,
like
they
kind
of
mentioned,
how
python
has,
I
guess,
dot
pi
c
files
that
it
creates
that
kind
of
cache,
the
sort
of
compilation
of
python
to
whatever
and
whether
that
would
make
sense
for
ruby
or
not?
And
the
conclusion
was
that
there's
probably
not
enough
optimization
going
on
in
the
compiler
to
make
it
worthwhile
but
yeah.
I
don't
know.
D
Probably
both
I
don't
know,
I
don't
know
how
long
it
takes
to
either
compile
down
to
those
instructions,
or
once
those
instructions
are
compiled
down
to
the
byte
code
that
the
vm
understands
like
how
long
it
takes
to
actually
run
those
instructions
versus
how
much
extra
memory
they
might
be
taking
up
or
any
sort
of
memory
optimizations.
That
might
be
possible
if
it
sees
other
keyword,
arguments
that
are
similar.
I
don't
know
if
it
can
kind
of
like
compress.
D
E
B
It
was
a
very
dry
chapter,
like
you
said
it
did,
make
me
appreciate
again
kind
of
the
magic
of
what
happened
with
ruby,
where
I
was
trying
to
think
back
to
like
the
1.8
to
1.9
migration.
I
don't
remember
any
like
any
migration.
I
had
to
do
myself,
I
kind
of
just
like
swapped
in
and
now
we
were
compiling
everything
and
nobody
even
really
noticed
it
was.
It
made
me
impressed
with
that
again.
E
D
So
what
I
was
kind
of
wondering
is,
since
they
started
the
chapter
by
saying,
ruby
1.8.
Let's
see
basically
like
interpreted
straight
onto
the
c
code.
If
I
remember
right,
whereas
in
ruby
one
nine,
we
had
a
virtual
machine
that
we
then
create
a
sort
of
byte
code
to
the
ruby
virtual
machine
I
was
wondering
is
that
basically,
just
like
a
different
type
of
machine
language,
like
does
the
virtual
machine?
D
Allow
you
to
have
like
to
specify
your
own
machine
language
that
you're
going
to
kind
of
compile
down
to,
and
I
just
thought
it
was
really
interesting
that
it's
still
after
going
to
the
yard
instructions.
It
still
has
to
interpret
to
see
and
then
go
to
machine
language.
So
I
just
feel
like
I
was
adding
an
extra
step.
Yet
somehow
it
sped
things
up
which
is
really
interesting
to.
D
C
C
C
D
Yeah
there
are
a
couple
lines
in
here,
so
I
don't
know
what
page
this
was
because
for
whatever
reason
my
kindle
book
just
has
like
locations
but
not
pages.
So
sorry,
I
can't
guide
you
to
the
exact
page,
but
it's
under
the
heading
ruby,
one
9
and
2.0
introduce
a
compiler
there's
a
few
paragraphs
in
it
says
the
primary
reason
for
using
yarv
is
speed.
Ruby,
1.9
and
2.0
run
much
faster
than
ub
1.8
due
to
the
use
of
yar
of
instructions
like
ruby,
1.8
jarv
is
an
interpreter,
just
a
faster
one.
D
C
D
Yeah
and
then
my
comment
on
this
next
one
was
just
interesting
because
I
didn't
know
what
else
to
like
say
about
it.
But
jarv
is
a
stack,
oriented
virtual
machine
and
I
was
like
okay,
which
means
when
yar
executes
your
code.
It
maintains
a
stack
of
values,
many
arguments
and
return
values
for
the
year
of
instruction.
D
E
D
Yeah
yeah
and
what's
interesting
about
that,
is
the
idea
of
the
development
rails,
environment
versus
a
production
rails
environment
where
in
production
it
caches
classes
which,
maybe
that's
just
the
normal
ruby
way
of
of
compiling
it,
whereas
in
development
it
lets,
you
add
things
to
a
class
and
it
will
sort
of
reinterpret
that
on
the
fly.
Somehow.
D
C
C
A
Points
the
like
the
thought
that
goes
through
my
head
is
just
like
my
javascript
mind
is
like
oh
we're
dealing
with
trees
like
maybe
it's
like
react,
and
you
can
invalidate
part
of
the
tree
based
on
what
changes
and
that's
what
allows
faster
reloading,
because
you
don't
have
to
recompile
the
entire
tree
somehow.
But
I
don't
know
it's
just
a
random
thought.
D
D
Maybe
it
runs
through
your
program
and
it
has
sort
of
a
redevelop
type
thing
going
on
in
it.
While
that's
running
in
the
console
or
in
the
terminal,
you
can't
go
into
the
file,
make
changes
and
expect
those
changes
to
show
up
in
your
live
running
program.
Right
like
it
will
have
already
gone
through
those
four
steps,
interpreted
the
whole
program
and
then
run
it,
and
just
because
you
change
stuff
in
the
file.
D
C
D
D
That's
kind
of
what
I'm
thinking,
so
that's
probably
why
development
is
so
much
slower,
or
at
least
always
perceived
as
slower,
because
it's
constantly
sort
of
reloading
files
and
I'm
wondering
if
it's
just
like
always
reloads
files,
every
request
or
if
it
only
does,
if
it
detects
it
changed
to
a
file.
But
anyway,.
D
I
also
thought
it
was
really
interesting
going
back
to
kind
of
the
kind
of
keyword
arguments
and
that
whole
line
of
thought
about
optional
arguments
and
block
parameters
and
the
rest
arguments
all
of
that
stuff.
It's
kind
of
interesting
that
it
sort
of
just
added
them
on
like
arg
feels
like
the
thing
that
was.
There
has
always
been
there
and
then
these
other
ones
were
sort
of
like
an
afterthought,
which
is
maybe
just
exactly
how
it
happened.
D
B
Yeah,
I
think
the
keyword
arguments
is
one
of
those
things
that
was
very
much
like
an
afterthought
and
they
kind
of
seeing
how
they
had
they
had
to
implement
that
it
seems
like
it
was
a
little
hackish,
I'm
not
saying,
there's
a
better
way
to
do
it,
but
yeah
that
was
just
like
they
worked
it
into
the
design
of
the
language
after
the
thought.
After
the
fact,
yeah.