►
From YouTube: Diagnostics WG meeting - 13 May 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
B
B
B
Yeah,
like
I
guess,
we've
had
other
ones
on
memory.
Like
all
the
other
use
cases,
the
use
cases
we
have
up
front
for
my
application
is
running
slower
than
it
should.
My
application
is
running
fine,
but
I
want
to
reduce
cost
to
my
application,
shows
spikes
of
CPU
usage
slowness
over
time,
so
this
one
might
be
like.
Maybe
it's
really
just
you're
using
too
much
CPU.
A
A
B
A
B
A
A
A
B
B
B
A
B
A
A
A
B
Just
thinking
that,
like
for
this
case,
it's
more
applicable
like
the
first
one,
if
there's
something
that
happens,
it
causes
you
particular
problems.
Those
may
just
happen
in
production,
and
so
it's
maybe
more
likely
in
the
case
of
I,
just
want
to
like
figure
out
where
most
of
my
CPU
time
is
being
used.
That
should
be
able
to
be
easier
to
recreate.
A
B
So
I
would
think
that,
like
in
this
one,
we
could
recommend
more
strongly
that
you
start
with.
You
know
trying
to
simulate
in
in
in
development,
and
then
you
use
the
same
tools
but
you're
using
them
for
longer
periods
of
time
to
get
more
data
and
and
hopefully
because
you're
doing
the
the
you
know,
you're
trying
to
get
the
the
more
common
case
is
what
you
want
to
cut.
You
want
effects
versus
the
uncommon
case.
B
A
C
D
B
C
B
D
B
A
A
B
B
C
B
B
A
B
A
A
A
A
B
B
That
one,
that
one
should
be
relatively
easy
because
you've
set
your
heap
to
a
certain
size
like
on
purpose,
almost
right,
although
that
there
are
cases
yeah
actually
having
said
that
like
it,
it
tends
to
use
as
much
heap
as
as
you'll
give
it
in
some
cases.
So
it
you
know
you
might.
You
might
actually
just
gone
with
the
defaults,
but
you
can
set
your
heap
limits
much
lower
in
some
cases.
A
B
But
but
the
thing
is:
reducing
the
reducing
the
heap
size
will
make
it
so
that
it's
collected
sooner
than
later,
and
if
nothing
else
it'll
definitely
reduce
your
virtual
size
right.
So,
like
you
know,
if
you
have
the
1.4
gig
keep
default,
the
GCE
may
just
never
decide
that
it
needs
to
collect
and
just
grow
your
virtual
21.4
and
potentially
swap
things
out.
A
A
A
B
A
A
A
A
A
B
A
A
B
Yeah,
it
basically
has
all
the
details
that
says:
I
can
see.
It's
got
read-only,
it's
got
the
heap
spaces,
so
read-only
space,
new
space,
old
space
code,
space
map,
space,
large
objects,
Base
new
large
object,
space,
so
I
think
diagnostic
report
shows
you
the
full
amounts,
the
folio
for
all
of
those
spaces.
A
B
Think
that
that
that's
a
good
suggestion
like
if
you're
trying
to
figure
out,
if
you're
using
more
memory
than
you
actually
needed
to,
then
you
know
if
you
consistently
force
a
GC,
do
a
diagnostic
report
as
or
sort
of
do
diagnostic
report
force,
the
GC
do
a
diagnostic
report.
If
those
numbers
are
substantially
different.
B
A
A
A
B
A
B
A
B
So
that
should
be
a
simple.
You
know
you,
you
think
that
would
actually
be
some
that's
simpler
than
what
it
already
does
right.
You
just
ignore
the
number
like
just
don't
when
you
were
gonna,
go
and
subtract
the
stuff.
That's
been
free,
just
don't
subtract
it,
so
that
ought
to
be
an
easy,
easy
option.
I
was
just
thinking
that,
because
you
know
one
way
to
try
and
avoid
things
being
freed
and
get
that
information
is
to
just
make
a
bigger
heat,
which
is
what
you
could
potentially
do
today.
B
A
B
A
A
A
B
Think
that's
worth
having
a
note
that
first,
you
want
to
see
whether
your
memory
is
being
liked
and
again
diagnostic
report.
I
think
we'll
have
some
information
about
like
whether
it's
what
the
process
memory
is
versus.
You
know
what
you
can
see
in
the
heap.
So
if
most
of
the
memory
is
somewhere
outside
of
the
heap,
then
you
do
want
to
look
at
where
that's
coming
from
and
I
haven't
used.
Val
grind
to
look
for
like
heavy
alligators,
mostly
leaks,
but
I
think
it
might
be
helpful
on
up
on
that
front.