►
From YouTube: Exploring memory usage in the Web IDE
Description
**Disclaimer:** a lot of finger-in-the-wind estimation is going on here... Please don't fret. The point is to get a general feel of some areas for deeper investigation.
**Related issue:** https://gitlab.com/gitlab-org/gitlab/issues/22737
A
So
I'm
just
gonna
share
something
I
just
discovered
recently
about
our
web
IDE
here
I
have
it
opened
up
on
the
gitlab
project,
which
is
not
a
trivial
project,
has
lots
of
files,
so
there
is
a
lot
of
data
that's
being
loaded,
but
nonetheless,
it's
taking
up
of
each
tab
is
gonna,
take
up
about
a
gig
of
memory
loaded
for
this
very
huge
project,
but
you
look
at
it.
There's
not
a
lot
visually
going
on,
so
I
wonder
where
we
can
optimize
to
not
load
as
much
data
I
do
now.
A
A
The
number
of
files
at
this
top
level
and
in
deeper
on
I,
wonder
what
happens
if
we
started
expanding
a
bunch
of
trees,
but
let's
see
what's
the
actual
difference
between
the
number
files
in
this,
this
one
looks
like
it
has
three
files,
including
three
directories:
I
think
I
have
code
open
over
here.
Oh
man,
oh
I'm,
not
sharing
my
whole
screen.
Okay,
let
me
shrink
this.
A
Let's
see
how
many
files
we
have
in
our
gate,
lab
project
I,
wonder
if
I'm
able
to
answer
that
question
from
let's
see
if
I
guess
this,
how
many
files
and
look
at
that
project?
What
if
it
was
asked
this
question
before
I,
don't
see
it?
Oh
okay,
I'll
get
Ella's
files,
that's
perfect!
That's
exactly
what
I
do!
Okay!
So
let
me
open
up.
A
A
A
So
something
tells
me
it's
not
a
whole
lot
of
memory,
we're
storing
per
file,
there's
the
only
things
that
be
different
for
here.
So
I
wonder.
If
maybe
it
has
more
to
do
about
the
number
of
things
that
are
loaded
here
at
this
top
level,
folder
sort
of
what
happens
this
tab
when
I
start
expanding
things,
let's
just
start
expanding,
maybe
I
should
expand
going
up.
Yeah.
A
A
And
maybe
this
is
something
we
just
can't
we
can't
solve,
because
project
is
just
that
huge,
but
I
still
feel
like
there's
not
a
lot
of
visual
information
here
to
justify
almost
a
gig
of
data.
That's
behind
all
of
this
or
just
a
gig
of
memory.
That
includes
like
callback
functions
and
everything.
There's
got
to
be
a
lot
of
room
for
optimizing
care
I'm.
Almost
at
the
end
of
this,
oh
man,
here
we
go.
A
All
right,
okay,
and
that
seemed
too
bad.
It
may
be
another
gig
or
another,
another
hundred
megabytes
or
so
okay.
So
that's
interesting,
so
wonder
if
we
just
have
if
we
have
a
lot
of
top
level
folders
order,
how
much
of
the
difference
that
makes
of
just
how
many
are
on
here.
So
let's
say
that
maybe
there's
50
or
so
top
level,
folders
or
files
here,
maybe
a
hundred,
that's
something
we
can
do
to
our
small
little
project
here.
What
if
I,
have
this
checked
out?
A
A
A
A
A
A
A
A
It's
not
just
what's
loaded
here
in
the
file
tree,
that's
making
us
so
large.
It
is
literally
than
that
there
was
a
significant
number
of
files
and
I
know
that
eat.
There's
a
large
object
back
in
each
one
of
these
files.
Cuz
we
do
a
bit
of
they
have
a
bit
of
behavior
tied
to
each
one,
but
if
we
could
promote
that
logic
or
some
of
those
events
to
a
parent
container
so
that
we
not
may
be
registering
callbacks
for
each
one
of
these,
that
would
save
a
whole
lot.
A
A
If
I
go
back
to,
let
me
just
open
on
the
oh,
okay,
all
right.
Let
me
go
to
my
projects.
Gdk
get
labs
files,
wcl
nice,
so
that's
there
should
be
like
2,800
files
being
loaded,
and
here
there's
like
200,
so
the
difference
is
pretty
negligible,
but
to
get
like
some
sort
of
baseline
memory,
that's
happening
for
the
web
ID
to
work.
A
There's,
let's
just
subtract.
80
megabytes
from
this
thing.
So
I
get
my
calculator
out,
I
know,
I,
know
950
minus
80
and
then
let's
divide
that
by
28,
and
so
it
looks
like
each
individual
files
because
that's
28
and
there's
2100
of
these.
So
if
I
divide
by
a
thousand
each
individual
file
is
0.03
of
a
megabyte
which
is
gonna,
be
if
there's
a
thousand
kilobytes
in
a
megabyte.
I
guess
this
is
31
kilobytes.
So
every
30
files
is
a
new
bag
of
I'd.
Is
that
right?
A
A
Yes,
let's
see
it
here:
oh
yeah
where's,
my
where's,
my
calculator
well
I
killed
it
I,
guess
very
create
200,
more
files,
so
a
little
200
times
0.03
should
have
been
six
more
megabytes,
so
just
for
fun.
Let's
do
that
same
little
exercise
again
and
compare
here.
We
had
seventy
nine
megabytes,
let's
see
if
it
just
pumps
it
up
by
six,
more
megabytes,
good
all
right.
So
what
did
I
do?
A
A
A
Here
I
am
alright.
I
refresh
this.
So
this
is
at
seventy
nine
point.
Four
megabytes:
let's
just
write
that
down
before
I
forget
it
as
I
will
for
you.
Seventy
nine
point,
four
megabytes
approximately
two
hundred
files
and
then
now
we're
gonna,
be
at
approximately
four
hundred
files.
I
know
it's
very
scientific.
Let's
refresh
it.
A
Okay,
do
we
have
all
those
you
know?
It
looks
like.
We've
got
all
the
stuff,
okay
and
how
much
memory
are
we
taking
okay,
we
bumped
to
125
significant
jump.
It's
probably,
though
too,
because
a
lot
of
these
files
are
open
or
very
visible.
So
there's
not
just
the
file
data
with
tracking,
but
also
the
data
that
is
being
displayed,
displayed,
displaying
the
components
themselves.
A
A
A
A
Ok,
so
yeah
I
was
kind
of
predicting.
We
were
predicting
a
0.3
or
we
were
taking
30
kilobytes
of
that
we're
storing
per
file
and
yeah.
Well,
we
have
20,000
28,000
files,
that's
gonna,
be
quite
big,
so
just
to
confirm
back
with
our
calculator,
carry
on
I,
get
lab
project,
there's
20,000
files
times
30
kilobytes
then
divided
by
a
thousand
yeah.
That's
just
storing
the
data
behind
each
one
of
the
files
and
you're
like
well.
You
know
30
kilobytes,
isn't
that
bad,
but
if
you
look
at
it,
what
actually
are
restoring
here?
A
A
That's
a
big
hitter,
because
that
caused
it
to
boost
pretty
severely,
but
most
projects
are
gonna
have
like
400
top
level
files
and
directories,
but
if
I
have
a
lot
of
stuff,
this
is
tucked
away
and
buy
a
lot
of
stuff.
I
used
to
think
that
maybe
having
a
28,000
project
was
a
little
unreasonable,
but
I
didn't
realize.
I
was
working
in
one.
That
was
twenty
eight
thousand
files.