►
From YouTube: Node.js community benchmarking WG meeting
A
Okay,
welcome
to
the
note
G
s:
community
benchmarking
work
meeting
for
January
15th
I
actually
forgot
to
start
the
meeting
a
little
bit
earlier,
so
a
present
so
far
is
myself
Michael
and
Benedict.
We
look
through
a
couple
of
the
issues
we
discussed
a
new
meeting
time
and
there's
a
proposal
that
we
alternate
this
meeting
every
other
Monday
and
Tuesday
I
at
2:00
Eastern
instead
of
three
Eastern.
So
you
can
take
a
look
at
issue
187
for
the
details
error.
A
B
We
all
I've
also
been
talking
about
this
to
re
and
couple
of
other
folks
and
I
think
the
way
that
eighty
cooks,
that
design
currently
and
fundamentally
works
against
the
performance,
optimization.
Okay,
so
by
now,
I
try
to
get
a
sense
of
what
what
is
actually
necessary.
So
I
think
you
have
been
in
the
design
as
well.
A
B
B
Okay,
implement
it
on
the
north
side,
so
we
b8
doesn't
know
when
a
promise
dies
right
because
yeah.
But
what
note
does
is
on
in
the
inner
took?
It
creates
a
wrapper
around
it.
A
super
stressed
wrapper
with
the
weak
reference
and
a
finalizer,
and
that
finalizer
is
run
when
the
object
dies
eventually.
D
B
A
Right,
I
guess
that
I
mean
I.
Think
in
the
case
of
like
the
post-mortem
debugging,
the
issue
is
around
unhandled
rejections
and
knowing
that
you
know
if
it's
been
rejected
and
it's
no
longer
reachable,
you
can
say
okay
well,
then
that
that
rejection
actually
was
unhandled,
whereas
otherwise,
you
know
somebody
could
add
a
handle
or
sometime
later
right.
B
A
B
B
A
B
A
A
But
people
don't
like
that
in
general
because
like
when
did
he
decide
it
was
truly
unhandled?
If
it's
because
that's
you
know,
that
was
the
the
focus
of
the
discussion
that
it's
hard
to
tell
when
it
really
is
one
that
matters
or
one
that
see
so
he
may
be
aggressively
deciding
to
crash
the
process
and
take
a
core
dump
right
yep.
A
E
A
You
really
until
until
you
can
no
longer
add
a
handler.
You
shouldn't
be
assuming
that
that
that
rejection
is
unhandled,
and
you
know
the
discussion
has
been
and
I
think,
there's
even
a
change
in
the
code
to
help
support
this
now.
I,
don't
know
if
it's
completely
right
or
landed
or
whatever,
but
Anna
had
made
one
which
basically
would
fork
the
process
on
unhandled
rejection
and
then
on,
like
on
GC.
So
when
the
the
hawk
went
with
the
promise
was
no
longer
reachable
or
when
you
stopped
the
process.
A
A
A
That
would
obviously
be
a
problem
too
right,
like
if
you
get
into
a
case
where
it's
just
there's,
never
enough
pressure
to
make
it
be
collected.
You
could
be
in
put
in
trouble,
but
there's
not
really.
A
good
answer
is
the
problem.
I,
you
know
somebody
I'm
working
with
at
the
University
of
U
and
B
is
also
looking
at.
Can
we
can
we
look
at
something
like
use
history,
so
you
know:
did
we
if
we
see
that
there
was
an
unhandled
rejection
when
we
we
finished?
E
B
A
Yeah,
so
that's
exactly
what
he's
looking
at
is
like.
Okay,
can
we
be
smart
in
terms
of
you
know,
learning
from
the
first
run
or
two,
and
then
you
say:
okay
well,
the
next
time
yeah.
This
is
actually
a
problem.
So
let's
get
the
diagnostic
information,
and
but
I
mentioned
that,
because
all
those
kind
of
count
on
being
able
to
you
know
may
need
the
destroy
part
in
addition
to
the
async
hooks
right.
A
B
These
intermediate
promises
don't
really
escape,
so
they
were
thinking
about.
Okay,
you
can
just
use
escape
analysis
and
scalar
replacement
and
just
completely
avoid
the
allocation
of
all
these
temporary
objects.
Yes,
because
what
you're
observing
promise
heavy
code
there's
a
lot
of
GC
traffic,
the
more
promises
you
use,
the
magis
sees
you
see
so.
A
B
D
A
A
B
B
We
need
to
pass
all
of
that.
To
note
note,
then
slips
the
ID
on
it
creates
a
wrapper
and
the
reference
only
there
to
support
the
destroy
hook
right
and
all
of
that
is
really
costly.
So
I
did
this
experiment
of
just
there
at
the
Bluebird
benchmark
stocks,
B
and
parallel
and
I,
just
added
a
Singh
cooks
to
the
benchmarks,
and
it's
more
than
2
X
lowdown
with
all
right,
putting
any
books
on
it.
Just
any
bring
a
city
codes
right
and
some
people
predicted
by
the
end
of
the
year.
E
E
B
So
we
could
do
this
ID
management,
so
what
we
couldn't
provide
this
right,
it's
the
promise
box
and,
as
an
embedded,
you
can
say
how
much
space
you
need
inside
each
promise
object.
So
no
20
says:
ok.
I
need
two
pointers
for
every
promise.
Why,
from
test?
Ok
I
need
one
point
us
yeah
and
you
these
point
us
to
put
an
ID
on
it,
which
is
one
then
two
to
put
a
reference
to
the
wrapper
object
on
it,
which
is
the
second
point
us,
but
this
ID
management
could
be
done
inside
of
the
Apes.
C
E
A
A
B
B
A
It
would
make
sense
like
if
there's
something
that
can
be
done
in
v8.
That
then
allows
it
to
be
optimized
better
I,
don't
see
why
people
wouldn't
go
for
that.
I
mean
I
think
that
discussion
is
probably
best
better
in
the
Diagnostics
group,
because
andreas
you
know,
and
the
people
working
on
the
async
hooks
all
the
way
like
I.
If
it's
not
real,
it's
not
strictly
async
ox.
It
may
be
a
more
general
discussion.
A
B
A
If
anything,
it
probably
would
make
sent
like
it
sounds
like
it's
so
correct
me
if
I'm
wrong
here,
but
it
sounds
to
me
like
there's
and
I
I
since
I
haven't
looked
at
that
specific
part
of
the
code.
I
can't
speak
to
that.
Well,
but
it
sounds
like
we
have
just
general
generally
in
node,
we've
added
something
so
that
we
can
tell
when
promises,
go
away,
yeah
and
that's
being
used
in
a
sing
cook,
so
I
think
it's
also
being
used
in
some
of
the
post-mortem
stuff.
A
B
C
A
C
A
Ask
the
questions
like
yeah
and
async
hooks:
is
it
really
necessary
or
not
people
should
chime
in
with
what
they
thought.
The
use
cases
were
and
then
that
that
can
hopefully
capture
enough
information
to
have
the
discussion
and
also
to
track
your
like.
If
there's
a
proposal
for
how
to
do
it
a
different
way.
A
D
B
A
B
Specifically,
the
section
and
yeah
I
put
the
numbers
in
there
and
you
see
the
if
you
scroll
down
to
the
next
page
yeah
and
you
see
the
graph
with
a
performance
impact
of
just
adding.
You
see,
there's
an
empty
in
it
hook,
so
it
doesn't,
it
really
literally
doesn't
do
anything,
but
the
performance
impact
is
pretty
pretty
high
on
both
the
bluebird
benchmark
and
the
Wikipedia
benchmark
right.
B
Yeah,
it's
not
doing
anything
except
creating
promises,
but
these
benchmarks
don't
even
do
any
IO
or
whatever
they
all
the
iOS
ma
taught
right
just
using
promises.
These
are
promise
benchmarks,
right
and
yeah.
I
think
that
there
is
a
more
serious
problem
about
the
other
parts
as
well
facing
hooks.
If
we
really
expect
the
servers
in
production
to
run
this
get
all
those
slows
down,
not
just
promises,
but
also
is
if,
on
every
IO,
a
bend
on
every
timer
yep
on
you
need
to
transition
between
C++
and
JavaScript.
A
A
B
B
D
A
B
What
it's
called
I'm,
not
sure
how
people
call
it
on
the
other
side
of
the
ocean.
I
think
Holly
always
says:
happy,
yeah,
okay,
about
the
benchmark
and
he
was
sort
of
excited,
although
he
doesn't
really
like
benchmarks-
and
he
already
wrote
articles
about
why
right,
but
using
it
as
a
driver
for
node
performance,
he
was
kind
of
excited
about
it.
Okay,.
D
A
B
D
A
Because
I
think
promises
are
gonna,
be
I
mean
it
they're
important
enough
that
we
should
be
good
to
have
a
benchmark
that
tracks
their
performance
and
we
don't
I,
don't
think
any
of
the
existing
things
that
we
have
do,
because
none
of
those
like
DCIS
and
Acme
air
I'm,
pretty
sure
the
code
doesn't
use
promises.
Heck
Mia
doesn't
know,
I'm,
not
sure
what
DC
mean
it.
A
B
A
B
B
B
A
C
B
A
Like
it's
sort
of
like
do
we
want
it
every
night
with
async
cooks,
it
seems
to
me
like
just
having
promises,
a
benchmark
that
tests
promises
in
general
every
night
wouldn't
be
bad,
because
it's
certainly
possible.
We
could
add
things
because
it
sounds
to
me
like,
even
without
a
cent
cooks
turned
on
shouldn't,
we
be
paying
the
penalty
of
of
knowing
when
it
when
promises
go
away
through
that
you
know
through
the
week
or
is
it
only
the
fact?
B
B
A
B
A
A
B
A
A
E
B
B
A
A
B
Think
and
fYI
would
be
good
for
everyone,
so
many
people
are
already
aware,
but
I
think
not
everyone
is
aware-
and
this
is
kind
of
cross-cutting-
its
performance
versus
post-mortem
reduce
other
diagnostic
tools.
Right
everything,
cooks
are
really
cross-cutting
and
specifically,
if
you
also
take
into
account
that
there's
this
push
for
more
promise
based
fbi's
in
no
time
yep.
B
A
A
E
E
B
A
D
C
A
B
A
C
A
C
E
A
B
So
everyone
is
the
way
that
the
performance
there
we
are
only
starting
to
look
now.
Rangi
I
spend
a
lot
of
time
improving
promises,
but
we
use
this
synthetic
benchmarks
and
now
we're
looking
at
how
this
integrates
with
yeah.
Now
there's
the
first
version
of
happy
that
it's
solely
based
on
promises
and
core
API.
It's
based
on
promises
and
just
starting
out
so.
A
I'm
going
to
okay,
so
I
have
PSE
review,
which
basically
says
you
know:
hey
can
every
know
TSE.
Can
you
take
a
look
at
this
yep
as
opposed
to
putting
it
on
the
agenda
where
then
it's
gonna
be
like?
Well,
what
decision
do
you
want
from
us?
So
I'll
just
put
the
label
for
TSE
review
on
to
that
one.
If
I
can
what
happened
here?
What
am.
A
A
C
A
A
A
I
think
it
was
up
to
at
least
a
hundred
and
forty
one.
Last
time,
I
heard
no
that's
cool.
The
goal
is
that
we
will
close
it
at
the
end
of
January,
so
Dan's
gonna
publicize
some
more
to
see
if
we
can
keep
getting
more
people,
and
so
I
wouldn't
be
surprised
if
we
can
get
closer
to
like
a
200
by
the
end
of
them.
The
month.
A
And
then
you
know
at
that
point
we'll
figure
out
like
within
K.
Can
we
make
all
this
data
public?
Can
we
strip
it
out
and
then,
as
a
team
here
we
should
probably
go
through
it
and
sort
of
say,
okay.
Well,
we
asked
these
first
set
of
questions.
What
does
it
mean?
What
do
we
think
it
means,
and
then
you
know
is
there
say:
do
we
need
a
follow-up
or
whatever
else,
but
yeah?
There
was
some
quite
interesting
data
there
just
to
start
with
yeah.