►
From YouTube: 2023-03-28 Source Code Performance Round Table
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
And
we're
life
Welcome
to
yet
another
source
code
performance
Roundtable,
and
this
week
we
have
already
we
have
items
in
the
agenda.
Do
you
want
to
Res
re
say
that
again
Charleston
your
your
first
coin,
yeah.
B
I
think
Alaska
time
was
the
first
one
at
least
the
first
one
that
I
joined,
and
we
talked
about
a
lot
of
different
things,
but
I
think
we
didn't
produce
any
external
outcomes
and
I
would
love
that
today
we
focus
more
on
outcomes.
Of
course,
when
a
meeting
is
new,
we
want
to
understand
what
we
want
to
achieve
now,
it's
the
second
time.
So,
let's
try
to
create
some
articles.
A
Yeah,
it
makes
sense,
I
think
one
of
the
things
that
I've
seen
is
capturing
the
discussions
we
have
in
issues
it's
beneficial
to
evolve
towards
those
outcomes.
I
know
that
we
have
some
discussions
last
week
that
don't
seem
to
have
resulted
in
issues
I,
don't
see
them
in
a
board.
So
that's
probably
like
one
of
the
homeworks
I
can
do
to
kind
of
make
sure
that
every
discussion
is
oops
is
an
issue
so
that'll
be
my
suggestion:
I'll
go
through
the
open
topics
and.
D
Let's
see,
maybe
we
can
draw
some
actionable
items
from
from
the
discussion.
A
All
right,
let's
go
tell
us
what
what
their
point
is.
Tennis,
that's.
D
The
point
is
that
technically
it's
like
seconding
the
the
question
I
raised
during
last
meeting
and
as
just
like
torsion
I
I'm,
not
sure
we
we
have
concluded
anything
anything
actionable
so,
but
the
consensus
seem
to
be
that
we
should
look
at
the
page
loading
performance
for
different
routes
and
talk
about
a
user
Journey
performance
optimization.
So
these
are
two
things
that
we
can.
D
D
So
if,
if
the
page
loading
the
initial
page,
loading
is
not
performant
enough,
then
the
user
Journey
won't
be
performant
enough,
so
maybe
it
makes
sense
to
actually
start
analyzing.
The
page
loading
performance
for
different
routes
that
we
have
I
have
linked.
The
I
have
added
the
link
to
the
dashboard,
which
lists
all
of
the
routes.
We
measure
at
the
moment
related
to
Source
editor
source
code,
I'm,
sorry,
I
confuse
the
things
again
to
Source
editor
again
source
code,
it's
muscle
memory,
it's
like
to
add
to
everything:
it's
actually.
D
It
contains
different
things
related
to
Source
header
as
well.
The
interesting
thing
is
that,
to
avoid
confusion,
probably
the
very
first
step
would
be
the
organizational
to
to
rename
the
routes
we
have
there,
because
if
you
take
a
look
at
the
dashboard,
there
will
be
routes,
labeled
editor
because
they're
related
to
Snippets
or
to
file
editing
and
those
are
source
code
now
right.
So
those
have
to
be
relabeled
so
that
we
have
a
better
review
of
these
things
under
our
responsibility.
D
So
the
dashboard
shows
that,
even
though
a
lot
of
the
a
lot
of
routes
like
most
of
the
routes
are
in
the
green
zone,
right
so
76.5
of
the
routes
are
in
the
green
zone,
it
doesn't
mean
that
they
are
performant,
because
most
of
them
are
still
loading
slower
than
one
second,
which
was
the
Paramount
like
about
five
years
ago,
and
we
still
haven't
reached
it
yet
right,
I
have
analyzed
a
couple
of
routes
and,
and
the
tendency
is
pretty
much
pretty
much
I
cannot
share
my
screen,
probably
to
make
things
a
bit
more
detail.
D
So
here's
the
dashboard.
So
all
of
these
things
are
related
to
us,
and
the
interesting
thing
is
that
so
the
the
I'm
not
sure
whether
the
file
blame
is
a
source
code
or
source
code
review,
I'm,
not
sure,
but
yeah.
D
B
D
That's
what
we
did
at
editor
at
at
least
we
just
pushed
the
things
to
other
groups
and
that
then
making
their
problems
right.
So
that's
yeah
I
can
give
some.
C
D
D
Yes,
that's
that's!
That's
the
thing
like
snippet
we,
on
the
other
hand,
we
have
like,
on
the
on
one
side
of
the
of
this
band
technical.
We
have
the
really
performant
pages,
so
the
Snippets,
Explorer,
Snippets,
dashboard
and
now
the
interesting
thing.
So
even
look
taking
a
look
at
this
dashboard.
We
can
make
a
really
simple
conclusion.
D
The
more
we
the
more
we
rely
on
view.
I
know
what
Andrea
will
hate
me
now,
but
the
more
we
rely
on
view,
the
the
harder
is
the
performance
hit
so
because
neither
Snippets
Explorer,
no
Snippets
dashboard
use
any
view.
These
are
straight
rails
views,
while
these
guys
are
like.
D
Lifters
right,
however,
this
doesn't
mean
that
we
do
not
need
to
go
to
to
refactor
things
to
view
what
it
means
is
that
we
have
to
be
very
careful
with
one
refractor
interview
and
no
understand
the
limitations
that
you
brings
to
Performance
table.
So
if
we
take
a
look
at
this
page
for
at
this
page,
for
example,
let
me
just
actually
let
me
just
share
the
whole
screen,
because
this
is,
let
me
just
stop,
sharing
and
share
again.
If
you
have
any
questions
in
the
meantime,
just
feel
free
to
ask
otherwise.
A
Yes,
so
coming
back
to
your
point
of
renaming
the
routes
from
editor
yeah,
my
understanding
is
like
the
key
here
is
the
URL
right,
yeah
yeah
sure
you
can
change
your
names
without
losing
the
history
or
starting.
D
D
The
URLs
here
won't
be
changed.
I!
Guess,
let
me
just
while
it
well,
it
might
be
changed
actually,
but
the
history
won't
be
affected.
The
the
URLs.
If
somebody
has
a
specific
route
bookmarked,
then
the
URL
might
be
changed,
but
the
history
will
be
there,
no
matter
what
so,
let's
talk
a
bit
about
the
about
this
blah
blah
love,
you
small
round!
This
is
it.
D
The
interesting
thing
that
we
have
here
is
that
blowview,
small
and
blobview
large
are
not
that
different
in
how
they
perform
right,
even
though
it
might
might
feel
like
they
have
to
be
different,
and
the
performance
of
this
page
is
very
interesting,
because
if
you
take
a
look-
oh
actually,
this
is
this
is
repo.
Where
is
this
yeah
love,
you
small?
So
if
we
take
a
look
at
the
performance
analysis
of
this
page,
the
film
strip
is
very
descriptive
thing.
D
So
when
a
user
gets
to
the
blob
view
page,
they
get
here
to
view
the
blob.
That's
why
it's
called
blob
view
page.
However,
the
actual
blob
content
is
near
is
nearly
North
prioritized
at
all.
So
this
the
content
triggers
the
LCP
and
it
happens
at
3.4
seconds.
However,
we
render
all
sorts
of
information
before
this.
This
happens
and
the
question
why
this
happens
is
our
sorry.
D
The
answer
to
the
question
why
this
happens
is
because
we
fetch
also,
this
is
the
the
these
are
the
fetch
requests
and
the
blob
content
is
fetched
as
the
very
very
last
request
in
the
stack
of
the
calls
we
can
do
much
better
than
that.
We
know
we
are
on
the
blob
view.
We
have
to
fetch
this
content
much
sooner
and
like
even
code
owners.
In
this
particular
case,
we
we
do
really
a
really
dramatic
thing.
We
fetch
all
of
the
code
owners,
even
though
we
don't
render
them.
D
We
do
fetch
all
of
them
like
160,
whatever,
like
crazy
number
of
of
code
donors.
So
things
like
this-
and
this
is
the
pattern
we
we
technically
have.
We
we
load
things
in
the
order.
They
appear
on
the
page
instead
of
low
prioritizing
the
the
things
that
are
really
important
for
that
or
or
another
page,
so
my
sort
of
to
wrap
it
up
to
wrap
up
this
ranting.
D
What
we
should
start
with
is
looking
at
that
dashboard
and
start
analyzing
the
the
routes
and
start
prioritizing
the
important
parts
on
every
route
that
goes
beyond
one
second,
namely
most
of
them,
because
this
will
dramatically
improve
the
LCP
of
the
rails,
and
this
will
dramatically
improve
the
user
Journey
as
we
as
the
next
step
in
the
performance
story
that
we
will
optimize
for
at
that
second
stage.
We
have
like
this
really
high
level
discussions,
as
we
had
with
torsion
about
the
in-context
editing
in
the
repository.
D
This
will
affect
the
performance
of
the
user
Journey,
where
we
switch
from
viewing
a
Blog
to
editing
a
view
without
reloading
the
page.
So
we
do
this
in
context
Swap
and
that
will
reduce
the
the
time
for
the
for
the
overall
user
Journey.
But
we,
as
I,
said
before
we
optimize
for
user
Journey.
We
have
to
optimize
the
page
loading
times,
because
this
is
going
to
be
the
hit
in
the
user
Journey,
no
matter
what
this
is
the
first
visit
to
a
page
which
will
inevitably
affect
the
user
Journey
time
anyway.
A
B
Yes,
so
I
would
like,
if
it's
possible,
can
we
add
to
this
dashboard
the
popularity
of
these
Pages,
how
often
they're
being
called.
D
No,
we
cannot
do
that.
This
is
this.
Is
this:
is
this?
These
dashboards
are
not
connected
to
to
any
analytics
of
this
sort?
This
is
purely
to
to
run
the
performance
analysis
in
the
background
and
just
speed
out
the
report.
This.
B
D
No
correlation
to
the
so
technically
to
get
the
to
get
the
mapping
between
this
dashboard
and
the
popularity
we
have
to
build
the
popularity
dashboard
and
then
map
those
together.
But
it's
not
I,
don't
think
it's
possible
in
the
in
the
grafana
dashboard.
B
Okay,
we
got
the
data
out
of
grafana
into
siphon
so
that
in
science
we
could,
for
instance,
have
these
side
by
side.
D
I
I,
not
that
familiar
with
license
to
to
say
to
answer
this
question.
Unfortunately,
so.
A
Sisense
works
with
limited
licenses
models,
so
not
everybody
has
a
editor
license
to
create
dashboards
and
queries.
I,
for
example,
don't
have
one
mats
income
review.
Has
one
I,
don't
know
if
a
silly
do
you
have
a
license
to
license
editor.
A
To
create
dashboards
and
stuff,
maybe
Sean
has
it.
We
can
look
around
to
see
if
we
can
have
someone
take
a
look
at
that
option
because
I
feel
like
yes,
it's
a
definitely
an
important
variable
to
check
torsion.
So
thanks
for
that
suggestion,
I
think
if
it's
possible
to
do
you
have
to
be
on
that
side.
A
A
So
I'll
create
an
issue
to
track
that
that
particular
thing
about
creating
a
dashboard
that
crosses
performance,
metrics
and
or
again
process
of
these
pages,
with
a
popularity
by
patient
based
on
page
views,
even
if
it's
not
impossible
to
import
the
actual
metrics
into
size
sense.
As
long
as
we
have
the
same
listing
of
routes
on
the
dashboard,
we
can
cross-reference
them
manually,
I
mean.
B
Yeah,
it's
we
need
to
not
constantly
lock
this
up.
We
need
to
look
this
up
to
make
a
decision.
I
want
to
be
three
months
later.
We
look
it
up
again.
So
if
it's
on
two
different
dashboards,
that's
fine.
Okay,.
D
The
complexity
here
is
that,
for
example,
here
in
in
in
grafana,
we
have
several
entries
for
exactly
the
same
route
right,
so
how
this
this
will
create
the
complex
like
for
the
blob
view.
We
have
small
blob
view.
We
have
large
blob
view
and
it's,
but
it
for
the
for
the
popularity.
It's
still
the
same
blog
view
page
right.
B
D
C
D
D
This
is
a
good
question.
Let's,
let's
just
find
out,
we
never
know
unless
we
find.
B
Out,
maybe
that's
maybe
that's
the
reason
why
large
performs.
D
That's,
that's
probably
most
probably
that's
that's
the
thing,
so
we
select
gitlab,
we
go
to
large
repo
and
then
we
we're
going
to
open
up
this
repo
small
here,
oops,
okay,
repo
small.
So
we
are
gonna
analyze.
B
A
D
Interesting
like
what
what
particular
element
actually
triggers
the
the
LCP
on
initial
this,
so
we
are
on
this
small
repo
and
the
LCP
is
triggered
by.
Where
is
the
LSP?
Here
we
go
by.
D
What's
that
by
the
by
this
bar
seriously,
like
this
is
the
largest
man.
This
is.
This
is
ridiculous,
but
this
this
is
the
interesting
thing,
so
repo
small
performs
worse
than
the
large,
and
even
in
this
case
it's
not
the
actual
repo
list
that
triggers
the
LCP.
It's
the
it's
this
this
bar,
which
triggers
the
LCP,
which
is,
which
is
really
a
really
bizarre,
bizarre
thing.
D
Where
is
it
so
yeah?
So
we
are
we're
not
doing
very
good
here
and
then
on.
The
large
repo
the
LCP
is
is
triggered
by
the
by
this,
how
we
call
it
like
placeholder
for
the
repository
right
so
which
is
not
very
useful
either
in
general.
This
me,
this
technically
means
that
the
pages
in
particular
repository
are
performing
even
worse
than
the
numbers
tell
us
it's.
The
LCP
gets
trick
tricked
by
by
elements
that
have
nothing
to
do
with
actually
Repository,
unfortunately,
so
this
is
another
thing
we
have
to
probably
go.
D
Do
the
analysis
of
the
of
the
monitorings
and
figure
out
how
to
adjust
the
monitoring
so
that
we
would
get
useful
information
instead
of
information
on
the
elements
not
related
to
to
actual
Repository.
C
E
Yeah
yeah
I
just
wanted
first
to
ask
which
file
you
were
analyzing,
but
I
already
saw
that
it
was
like
just
main.js
I
just
checked
couple
files
now
and
I.
Don't
see
what
you
mentioned
about
the
code
owners
are
loaded
before
the
blob
in
first.
So
what
I
see
in
my
browser
everywhere,
like
first
reload
blog
data
and
then
reload
or
the
owners
so
I'm
just
confused.
D
E
E
E
Just
don't
show
them
at
all,
don't
throw
names
and
all,
and
then
we
will
fetch
like
once.
The
user
hits
the
expand
things.
So
this
is
something
you
shouldn't
worry
about.
D
Okay,
so
let's
those
are
the
thing
here,
so
we
have
some
some
error
thrown
here,
but
you
see
the
the
if
we
go
to
the
network
tab.
Do
you
see
my
screen
now.
E
D
D
Okay,
some
extensions
go
in
now,
but
the
blob
content
is
at
the
very
at
the
very
end
of
the
of
the
call
stack
and
if
you
take
a
look
at
the
the
waterfall
now
it's
okay,
let's
reload
this,
so
it's
not
the
last
one
now!
But
if
you
take
a
look
at
the
waterfall,
this
is
where
we
start
requesting
it.
E
D
A
I
added
a
note
below
Dennis
I
thought
I
thought
we
had
done
this
for
the
to
adding
that
this
startup.js
and
it
feels
like
we
only
added
that
to
the
blob
info
query,
but
not
to
the.
D
Be
I,
don't
know
this
again
as
I
didn't
do
any
any
deeper
research,
but
that's
so
we
we
fetched
the
we
fetched
the
repository
blob
information
as
the
very
first
thing.
This
is
great
yeah,
but
the
actual
content
comes
as
the
last
thing
and
we
cannot
really
use
startup
GS
for
for
the
content,
specifically
because
we
have
to
know
how
whether
we
have
to
fetch
the
content,
whether
we
show
the
simple
viewer
or
we
show
the
rich
viewer,
and
that
information
is
based
on
right
on
this.
Very
first
query.
D
So
we
cannot
really
put
this
into
the
startup.gs,
but
we
can
optimize
the
things
so
that
we
once
we
get
the
blob
the
general
repository
blob
information.
We
fetch
the
blob
blob
content
right
away.
Apparently
I,
don't
know
I'm
just
speculating
now,
because
I
didn't
do
this.
But
that's
that's
that's
the
reason
why
we
cannot
use
blob
content.
Query.
A
Oh,
that
sort
of
GS
that's
great.
What
I'll
do
is
I
won't
open
issue,
saying,
like
add
blob
contents
to
startup.js,
but
I'll
say
that
find
a
way
to
prioritize
blob
content
loading.
D
Yeah
I
think
we
have
I,
think
I
think
it
would
make
sense
to
have
something
like
you
know,
epic,
at
some
point,
to
go
through
the
different
routes,
because
we're
talking
about
the
blob
now
blob
viewer
now.
But
there
are
multiple
routes
that
that
we
we
will
benefit
from
prioritizing
the
actually
important
parts.
So
that's,
but
we
can
start
with
with
The
Blob
viewer,
as
is
one
of
the
probably
most
used
routes
and
repost
repo
view.
Probably
I,
don't
know.
D
So
again,
to
wrap
up
this
whole
point
that
I
took
took
all
the
time.
Excuse
me,
but
I
think
we
have
to
prioritize
the
the
page
loading
performance
before
we
get
to
the
user
Journey
performance,
because
this
part,
even
looking
at
the
numbers
numbers
are
okayish,
but
they
do
not
reflect
the
real,
the
real
situation.
It's
the
the
actual
performance
that
users
experience
might
be
worse
because
we
we
just
trigger
LCP
on
the
wrong
elements.
D
A
So
with
that
in
mind,
I
wanted
to
ask
you
this
before
I
move
on
so
I
I
thought
we
had
done
this,
but
it
seems
like
we
haven't
from
my
inspection.
We
don't
have
performance
marks
on
this
app
and
it
feels
like
this
example
of
having
two
repos
being
triggering
different
lcpe
elements
like
shouldn't
shouldn't.
We,
because
this
is
very
familiar
to
you,
because
you
added
the
first
one
still
gitlab
shouldn't.
A
D
D
There,
that's
that's.
The
thing
that
we
should
should
be
should
should
optimize
for
so
for
those
who
are
not
familiar
with
this
many
many
years
ago,
when
the
world
was
much
better
place
to
live
in
I,
we
added
we
started
using
the
user
timing
Matrix,
so
the
custom
metrics
in
the
product
which
didn't
get
a
wide
adoption,
simply
because
they
are
really
custom
metrics,
so
for
they
allow
to
measure
exactly
the
thing.
D
D
What
it
allows
us
to
do
is,
for
example,
when
we
talk
about
the
blob
blob
viewer,
we
can
set
a
special
Mark
in
the
code
saying
marking
the
time
when
the
actual
blob
content
has
been
output
on
the
screen,
and
that's
the
the
that's,
the
real
measurement
of
performance
for
that
or
another
View,
for
example,
when
it
comes
to
the
reposed
review
the
the
time
when
the
files
have
been
output,
not
this
Skeleton
thing,
but
the
actual
files
have
been
output.
This
is
the
the
measurement
of
performance.
D
I
I
have
implemented
a
bunch
of
these
things
in
the
in
the
product.
We
also
have
a
view
plugin
for
view
components
very
few
people
know
about
that,
but
simply
because
I
was
tired
of
pushing
for
this
at
something
it
was
like.
D
Written
Dennis,
oh
man,
we
even
we
even
had
the
con
I
think
I
even
mentioned
this
during
the
Prague
conference
call
conference
like
session
so
yeah,
but
nevertheless
there
are,
if
you,
if
you
go
to
to
and
I
actually
I,
think
on
the
blob
view
we
do
have
those
marks.
We
do
have
custom
user
marks.
Let
me
just
double
check,
but
we
can
talk
about
other
things
regardless.
A
Yes,
let's
move
on
to
the
next
plane
in
the
agenda
which
I
think
Vasily
you
wanna
mention
your
brain
yeah.
C
I
just
like
so
that
we
have
the
plane.
Endpoint
is
quite
it's
like
one
of
the
top
endpoints
that
we
have
and
I
just
remembered.
I
wanted
to
share
that
recently.
The
stanislap
was
working
on
including
streaming
to
this
endpoint
I'm,
not
sure
if
it
was
enabled
because
it
was
deployed
before
behind
the
feature
flag,
but
we
might
see
some
improvements
for
it.
A
Thanks
facilities
so
recently
Jack
and
the
Vasily
collaborated
to
add
one
URL.
That
will
be
inheriting
the
streaming
when
the
feature
kicks
in.
So
essentially
we
have
a
a
URL,
so
the
blame
Page
by
default
lowers
the
paginated
version.
Then
we
have
the
nopagination
parameter
right
right
now.
The
no
pagination
is
just
the
old
way
of
rendering
the
full
page
and
it
breaks
and
all
that
stuff,
when
the
paid
when
the
streaming
gets
enabled
that
page
no
pagination
will
start
streaming.
A
We
added
the
no
pagination
to
the
site,
speed
dashboards
before
the
site.
The
streaming
was
enabled
so
that
we
can
we
get
to
compare
the
two
I
haven't
looked
at
it.
Yet,
though,
so
take
a
look
right
now.
A
I
don't
see
it
yet,
but
so
yeah,
it's
there
added
that
to
the
site,
speed
or
let's
find
a
way
to
track
that
performance
impact.
D
No
I,
when
I,
when
I,
saw
that
that
HTML
streaming
thing
like
that
was
that
that
the
series
started
that
no
it
was.
It
was
stanislav
who
was
working
with
that
thing
right
so
and
that
that
was
super
cool.
That's
that's
amazing,
stuff.
So
I'm
I
really
hope
to
see
more
of
that
foreign.
A
Yes,
this
was
the
first
time
that
this
was
rolled
out
to
any
part
of
the
git
lab
and
we're
looking
to
learn
about
it
and
potentially
try
to
bring
it
over
to
code
review
as
well,
because
you
know
standards
live,
is
good
review
he's
also
my
team
so
to
personalities
here,
yeah
we're
looking
to
learn
from
this
rollout
on
the
blame
page
and
see
the
impact
of
it
all
and
there's
also
even
more
steps
that
we
can
start
doing
instead
of
rendering
things
in
the
back
end.
A
Thanks
vasili
all
right
Dennis,
you
have
another
point.
D
D
The
entries
in
the
site,
speed,
dashboard,
then
update
analyze,
the
things,
the
analyze,
the
routes
and
use
user
timing,
user
custom
timing
metrics
to
measure
what
really
matters
for
that
or
another
route
that
would
be
would
be
interesting
work,
and
maybe
we
could
do
this
in
the
form
of
pair
programming
so
that
more
people
would
know
about
this
about
how
to
do
this,
so
anybody
willing
to
to
participate
would
be
would
be
welcome.
D
Probably
so
we
update
the
metrics
and
then
we
will
have
the
proper,
proper
understanding
of
real
performance
of
that
or
another
page.
At
the
same
time,
we
try
to
find
the
the
popularity
of
all
the
pages
that
we
are
responsible
for
and
try
to
some
somehow
map
the
performance
dashboard.
With
with
that
statistics,
to
figure
out
like
technically
from
my
understanding,
this
will
give
us
the
priorities.
D
What
we
use
should
be
prioritized
for
that
or
another
performance
work,
because
we
might
spend
our
time
for
optimizing,
something
that
is
barely
used
in
the
product.
So
that's
that's
good,
starting
starting
point,
I,
think
and
after
that
we
will
be
able
to
talk
about
the
user,
Journey
optimizations.
D
B
A
B
The
meanwhile,
edit
here
a
statistic
and
extended
it
to
include
the
blame
page
on
the
main
page,
is
very
little
used,
which,
if
I
didn't
make
a
mistake.
B
So
the
main
page
is
down
here
it's
up
to
10
000,
and
this
is
up
to
400
000,
which
is
the
directory.
So
that's
the
not
the
blob.
That's
the
other
one.
B
Then
we
have
a
bunch
here
in
that
Middle
Field
like
commit
details
like
files
and
so
the
file
file
view
the
plot
View
and
the
commit
list
I'm
doing
this
by
looking
for
things
in
the
URLs
like
this,
which
is
a
bit
dangerous
because
there
could
be
something
like
commits
somewhere
else
that
isn't
you
know,
really
commits,
or
so
that's
how
I
did
it
and
that
if
you
have
better
ideas
how
to
make
this
more
safe,
please
let
me
know.
D
This
is
this
is
really
helpful
because.
A
Probably
at
the
slash
Dash
on
that
pattern,
matching
person.
Sorry
Dennis!
Sorry,
so
you
know
how
the
URLs
have
a
slash
Dash,
so
that
we
can
distinct.
C
A
For
example,
if
you
put
that
in
the
string,
lookup
I'm
guessing
that
that
will
prevent
Branch
names
for
being
picked
up
on
that
it.
D
A
B
If
I
put,
if
I
do
this
here,
what
will
be
the
effect?
Will
I
only
pick
up
like
the
default
Branch
or.
D
Or
project
or
project
blame
or
pay
or
repository,
called
blame,
or
something
like
this,
because
Brian's.
A
A
B
So,
even
if
I
go
to
a
different
Range
Branch,
it
still
has
this.
Okay.
A
B
About
I
have
also
things
like
graph
of
that
habit
as
well.
D
At
this
at
this,
this
chart
made
me
look
at
the
performance
dashboard
and
actually
we
do
not
monitor
performance
of
the
commit
and
commits
pledges
at
all.
So
probably,
we
need
to
to
align
this
this
chart
with
with
what
we
measure,
because
if
the
commits
are
like
commit
view
or
commits
listing
are
pages
with
a
lot
of
views,
then
probably
we
should
start
monitoring
those
and
optimize
those
as
well.
A
That's
a
great
opportunity
to
clarify
that,
so
what
atal
is
talking
about
is
the
quality
teams,
10K
reference
architecture,
performance
reports-
in
that
case
they
have
their
own
cases,
their
own
pages,
that
they
monitor
and
that's
you
know,
a
reference
architecture
for
10,
000
users,
installation
of
gitlab,
that's
something
that
they
run
on
a
separate
instance
in
a
controlled
environment
requesting
its
own
URLs
and
that's
produced
daily.
A
The
site,
speed
page
that
we're
looking
at
is
monitoring
live
URLs
in
production,
they're
different
Pro,
the
different
monitoring
projects.
They
aim
to
cover
the
same
ground,
but
slightly
different,
where
one
is
live:
URLs
on
production
affected
by
outages
and
delays
and
stuff,
like
that,
the
other
is
a
control
environment
to
capture
regressions
right
here,
we're
looking
at
like
actual
live
metrics
there.
So
Dennis
is
calling
out
that
we're
not
we
don't
have
an
entry
on
the
site.
Speed
live,
gitla.com,
URLs
to
track,
commits
and
I
just
checked.
A
D
D
The
the
question
is,
though,
whether
so
from
by
commits
I
assume
the
list
of
commits
in
in
an
MR
or
in
the
Repository.
That's.
B
A
Also,
we
also
track
a
project
commit
I'll,
put
the
link
in
the
agenda,
so
you
can
all
take
a
look
at
the
report.
Okay,.
D
D
B
Well,
let
me
run
it
again:
I
fix
it
now.
Maybe
it
had
to
do
with
you
know
that
being
part
of
some
URLs
right.
A
C
A
Again,
I
wanted
to
say
something
before
we
have
to
understand
that
the
blame
page
is
very
small
compared
to
others,
so
the
relative
popularity
is
definitely
low.
However,
when
the
user
needs
a
blank
page
and
if
they
go
to
the
to
the
to
the
web
version,
It's,
usually
motivated
by
you,
want
to
share
it
in
a
discussion.
So
it's
particularly
useful
even
if
it's
low
visited
so
it's
kind
of
like
and
there's
another
thing
where,
if
the
page
is
slow,
people
stop
using
it
as
much
so
I'm
making
it
faster.
A
Theoretically,
we
can
track
the
increasing
popularity
here
too
that's
selling
Theory,
but
yeah.
It's
very
useful
to
have
it,
though,.
D
It's
with
with
performance,
it's
always
like
the
Chicken
and
the
Egg
question
like
do
people
visit
this
page
rarely
because
of
the
bad
performance
or
is
the
bad
performance
attributed
to
the
fact
that
the
page
is
not
popular
enough,
so
it
doesn't
get
any
any
attention.
B
B
It
remains
that
the
commit
detail
and
commit
list
are
rather
popular
together
with
files
and
all
right.
That's
that
one
that
are
not
relevant.
B
B
So
it
seems
you
should
we
should
check
that
other
dashboard,
that
Talia
mentioned
in
terms
of
performance,
because
that
might
be
more
relevant
than
the
blank
page.
B
Oh
I
would
suggest:
let's,
let's
look
at
the
dashboard.
That
Natalia
mentioned
in
terms
of
you
know,
commits
and
commit
a
detailed
View
to
see
how
those
perform
and
if
they
don't
perform
well,
it
would
probably
be
more
important
to
fix
those
than
the
main
page
because
of
it
significantly
more
higher
popularity.
B
Admittedly,
popularity
can
go
up
if
performance
goes
up,
so
there
is
a
bit
of
a
chicken
and
egg
problem.
But
if
commits
and
commit
detailed
view
are
important,
then
we
should,
and
slowly
should
fix
those
people.
A
So
this
is
from
weight.
Still
loading
there
you
go.
This
is
from
the
10K
performance
architecture.
So
if
you
come
here
right
out
on
this
top,
you
have
a
results.
History,
dashboard,
which
will
take
you
to
a
full-on
dashboard
on
on
grafana
with
all
the
metrics
here.
Then,
if
you
go
to
site
speed
report,
that's
where
you
get
the
actual
report.
A
Sorry,
that's
a
report
for
each
one
of
the
URLs
tested.
You
can
drill
down
if
you
want,
but
zooming
in
on
LCP,
for
example,
if
we
want
to
see
compare
to
file
rendered
so
it
looks
like
we
had
a
spec
here
Branch
if
I
blame
these
are
the
the
relative
LCP,
so
they're
pretty
high,
and
here
one
is
a
project
commit
page
which
is
the
details
of
a
commit.
This
one
here
is
the
list
of
commits.
A
So
if
you
have
to
compare
between
those
two
commit
detail,
Pages,
definitely
worse
offender,
it's
on
the
red,
so
it's
above
the
threshold,
so
is
the
file
render,
but
then
again
we
and
then
have
to
see
how
big
is
the
file
rendered.
A
C
B
A
A
Okay,
I
added
one
last
Point
here:
does
anybody
have
any
other
thoughts
on
this
topic
that
we're
just
discussing
or
can
I
move
on
to
this
last
one.
A
Thank
you,
I
was
giving
some
awkward
pause
so
I'm
bringing
up
these
two
proposals,
so
Dennis
previously
talked
about
the
user,
Journey
metrics
and
improving
the
the
time
that
gets
the
use
to
the
destination.
What
they're
trying
to
get
to
so
there
are
two
particular
issues
that
they're
like
low
visibility,
low
effort,
also
I,
would
say
low
effort,
Famous
Last,
Words
proposals.
A
One
is
to
add
a
little
pop
over
with
blame
information
for
that
particular
line
on
the
gutter
on
the
line
numbers
which,
essentially,
if
we
have
a
back-end
endpoint
to
get
the
blame
information
for
a
specific
line
like
we,
the
front
end,
could
sort
it
out
and
present
it
on
popover
and
we
can
load
it
only
when
the
user
pops
over
that
part,
so
it
performance
wise
only
generates
load
when
we
need
to
so
that's
one
proposal
which
sometimes
user
just
wants
to
see
the
blame
information
of
one
particular
line
that
would
prevent
the
user
from
going
to
the
whole
full
blame
page
and
then
have
to
render
the
whole
thing
just
to
see
online
and
the
other
is
a
proposal
that
goes
a
little
bit
beyond
that,
and
essentially
is
a
like
a
drastic
proposal
to,
instead
of
having
a
separate
blame
page,
we
could
be
rendering
them
blame
information
for
all
Lines
within
the
blob
viewer.
A
So
essentially,
when
you're
seeing
a
blob
content,
The
Blob
page
itself,
we
could
potentially
toggle
the
mode
to
blame.
The
show
blame
information
instead
of
reloading
a
whole
nother
page
with
the
whole
nother
file.
Contents
again
presented
in
different
ways.
We
could
just
request
the
remainder
of
the
information
necessary
to
render
the
blame
page
in
portions,
just
the
portion
that
the
user
is
viewing
and
then
eventually
stream
the
rest,
which
could
potentially
be
very
beneficial
for
the
end
goal
of
reaching
the
blame
information.
A
So
I
wanted
to
raise
visibility
for
these
two,
because
the
aim
of
them
is
to
increase,
prefer
improve
the
performance
metric
of
the
user
Journey
that
user
wants
to
get
to
the
blame
page
without
having
to
you
know,
redo
the
whole
blame
page.
It
just
brings
things
over
to
the
blob
information
page,
the
blog
page,
so
yeah
when
it
raised
visibility.
You
have
thoughts,
we
have
five
minutes,
but
if
not
feel
free
to
add
them
in
the
issues.
A
D
Have
a
question:
yes,
yes,
I
like
this,
this
proposals
they
they
really
nicely
align
with
the
with
the
idea
of
doing
in
context,
editing
and
the
inline
editing
as
a
torsion
proposed.
D
During
our
chat
this
week,
but
the
question
I
have
is
by
improving
the
user,
Journey
For,
the
Blind
page
here,
won't
we
harm
the
loading
performance
for
the
live
view
page
because,
let's
assume
we're
getting
rid
of
chunks
pretty
soon
and
we
have
a
blob
view
for
a
thousand
lines.
D
A
A
So
if
we
have
new
tech
powering
the
blame
page,
we
can
be
smarter
about
loading,
the
data
we
don't
have
to
load
the
entire
thing
and
eventually,
if
we
refactor
the
blame
page
eventually,
part
of
that
work
would
be
essentially
building
the
blog
page
again.
So
my
idea
or
for
for
the
first
one.
Definitely
it's
not
replacing
the
blame
page.
The
second
could
potentially
replace
the
blame
page.
If
we
get
to
a
better
performance
place
and
I'll
stop
there.
A
E
I
would
I
want
to
say
that
like
I,
don't
think
I
like
the
idea
of
throwing
the
blame
information
to
the
user
without
request
so,
for
example,
I
as
a
user
I,
don't
want
to
know
like
but
like
info.
Unless
there
is
some
button
you
pressed
and
then
we
can
load
it
on
the
same
like
blob
right
page
but
yeah
not
like
from
the
start.
I
think.
E
A
But
okay
so
probably
worried.
A
D
D
E
A
Go
and
add
these
comments
on
the
issue
right
now,
so
we
don't
forget,
because
all
of
that
will
be
information
for
Michael
lay
the
designer
to
kind
of
like
help
us
drive.
That
proposal
through
that's
good,
great
questions.
That's
why
I
brought
this
up
so
they're
already
better
proposals,
because
of
this
any
more
thoughts
on
that.
Can
we
wrap
up.
A
D
A
So
I've
taken
much
so
every
open
issue
to
track
Bulls
statements.
I
will
take
care
of
so
essentially
that
covers
the
things
you
highlighted
the
priorities
so
relabel
the
entry.
There's
an
issue
dashboard.
There's
an
issue
commits
there's
going
to
be
an
issue
that
metrics
to
measure
correct
things,
also
going
to
be
an
issue
and
prioritize.
The
love
is
going
to
be
issue
yeah.
We
have
issues
for
all
that
I'll
create
all
those
issues
and
add.