►
From YouTube: WebPerfWG call 2022 03 03 - JS profiling sampling rate
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
All
right,
okay,
all
right
thanks!
You
have
so
yeah,
so
it's
gonna
be
a
rather
a
brief
presentation.
I'll
start
with
a
quick
summary
and
dive
into
the
question
and
feedback.
He
was
looking
for
from
this
forum.
A
So
so
recently
this
has
been
interest
from
industry
partners
into
lowering
the
sampling
interval
of
the
shift
implementation
of
the
gs
profiling
api-
and
I
wanted
to
reach
out
to
this
group
to
leverage
your
past
experiences
with
a
high
resolution
timer
to
help
figure
out
if
the
spec
for
the
gsl
profiling
api
should
be
maybe
more
specific
into
what
are
the
same
sampling
interval
that
we,
that
user
agents
may
support
and
yeah
and
maybe
touch
upon
the
security
aspect
of
it
all
so
very
quickly.
A
What
is
the
js
profiling
api?
It's
a
webexposed
sampling
profiler
that
which
is
really
useful
to
help
dive
into
the
performance
issues
of
gs
code
that
shipped
on
user
devices.
So
you
get
actual
performance
characteristics
from
real
user
devices.
How
do
you
create
a
profiler?
So
you
have
this
interface,
you
define
simple
intervals
of
microsize.
A
A
So
you
have
the
frame,
the
resources,
the
samples
and
the
stacks
and
so
yeah
going
into
the
question.
So
blink
is
interested
in
to
lowering
the
resolution
to
one
millisecond
compared
from
the
ship
resolution
that
was
10
milliseconds.
A
The
specification
itself
leaves
open
to
user
agent,
the
resolution
that
they
they
may
support
and
obviously
for
such
an
api,
the
risk
is
to
introduce
another
source
of
high
resolution
timer
that
could
be
used
in
timing
attacks
regarding
the
security
consideration.
So
I
believe
the
api
shipped
with
a
10
millisecond
mean
sampling
resolution,
because
the
discussion
on
the
high
resolution
timer
wasn't
settled
at
the
time.
A
The
timestamps
themselves,
in
the
stack
trace
that
you
saw
earlier,
are
actually
fetch
using
the
high
resolution
timer
defining
the
hr
time
specification,
and
so
we've
had
an
initial
security
review
performed
by
an
industry
partner
at
microsoft
for
the
bleak
implementation,
and
his
conclusion
was
that,
since
the
proposed
new
sample
interval
of
10
milliseconds
of
one
millisecond
is
10x
the
resolution
of
hr
time
in
a
non-cross-original
solidity
context,
he
concluded
that
that
would
be
a
low
risk
to
be
used
in
timing
attacks.
A
So
this
brings
me
to
the
question
and
feedback
I
was
looking
for
from
this
forum,
which
is
so
from
a
specification
perspective.
Should
we
update
the
language
to
provide
advice
regarding
the
minimum
sampling
interval
that
may
be
supported,
especially
considering
that
the
timestamps
themselves
are
fetching
the
resolution
timer,
I
think
maybe
it
might
make
sense
to
define
them
relative
to
the
high
resolution
timer
itself.
A
So,
for
example,
from
the
paper,
I'm
from
the
security
analysis,
10x
was
considered
safe
but
would
be.
Would
the
same
resolution
be
safe
as
well
right,
yeah?
So
that's
what
I
have
for
you
today.