►
From YouTube: 2022-12-15 Code Review Performance Round Table
A
A
A
B
A
B
A
A
A
B
A
B
B
A
B
B
B
A
A
A
A
B
Chrome
doesn't
properly
cache
this
request,
even
if
we
add
like
a
cache
control
header,
that
you
must
cache
it
that
there
is
a
max
age
for
this
resource,
Chrome
still
doesn't
cache
it.
He
still
makes
a
request
to
the
server.
We
still
do
the
full
processing.
We
still
return
three
or
four
that
result
didn't
change,
but
there
is
a
round
trip
to
the
server
which
shouldn't
be
there.
We've
tested
it
in
Firefox
and
Firefox
doesn't
have
this
issue.
B
B
Not
there
is
a
different,
different
approach
to
http
cachings
that
is
working
right
now,
which
is
basically
sends
the
request
to
the
server
the
server
checks,
the
cache
key
and
returns
three
or
four
that
it
didn't
change.
So
we
basically
have
to
get
through
some
of
the
overhead
from
the
real
side.
It
takes
about
three
four
hundred
milliseconds
and
you
get
the
three
or
four
response
which
basically
tells
the
browser
to
reuse
the
previous
response.
B
So
it's
working,
but
it's
not
ideal,
and
what
we
want
to
do
is
to
remove
this
round
trip
to
the
server
at
all.
So
if
we
provide
the
cache
key
with
the
page
and
do
the
request,
the
browser
should
take
the
request
from
the
memory
immediately
the
cache
key
and
this
memory
cache
is
not
working
in
the
from
right
now
for
us
right.
B
A
A
B
B
Not
really
because
we
are
actually
blocked
by
a
lot
of
things.
First
of
all,
the
migrations
that
we
do
are
not
backwards
compatible,
so
the
branch
I
was
working
on
stopped
working
after
I,
updated
jdk
and
after
we
rebased
of
the
latest
semester.
It
also
stopped
working
because
some
some
changes
in
gitlab
UI
for
some
reason
made
it
broken.
And
the
third
thing
is
that
gitlab
UI
actually
reverted
the
bootstrap
view
upgrade
so
yeah
right.
B
We
discussed
it
previously,
I,
guess
and
like
it,
it
looks
simple
on
the
surface,
like
you
said,
it's
just
like
few
components
that
we
convert
to
view
templates
and
rails
yeah.
It's
not
that
simple!
Actually,
because
we
do
a
lot
of
Transformations,
I've
looked
up
the
code
and
it
transforms
the
data
required
to
render
these
lines
into
some
new
structures.
B
A
Yeah
the
question
the
question
of
that
I'm,
not
so
worried
about
the
server-side,
rendering
itself
I'm
more
concerned
about
how
how
do
we
hydrate
it
later?
How
do
we
make
you
know
after
thing
is
put
on
the
page?
How
do
we
bring
it
to
life?
Is
that
fast
is
this?
Is
that
slow
is?
Is
there
any
hurdles.
B
I
I
will
definitely
say
it
will
be
much
faster,
but
the
problem
is
that
the
code
won't
be
as
declarative
as
it
is
right
now,
like
we
just
mutate.
The
state
and
discussions
appear
on
these
divs
and
it
all
just
works
with
a
new
approach.
We'll
have
to
do
more
manual
work,
but
the
performance
will
be
much
much
faster,
as
that
is
that
is
for
sure.
A
B
A
B
B
A
Yeah,
so
the
two
things
one,
the
the
father-
are
too
large,
we're
already
truncating
them
at
a
certain
point.
So
that's
already
done
and
if
anything
we
would
like
to
move
away
from
that
truncation.
But
that's
another
story
here
is
more
like
you
run
a
project
that
generates
a
lot
of
automated
files.
So
why
should
those
need
to
be
reviewed
I'm
of
the
mind
that
any
file
on
the
merger
Quest
needs
to
be
reviewed?
Otherwise
it
could
be
a
vehicle
for
a
vector
for
attack,
but
that's
other
stories
here.
Yeah.
A
B
B
A
So
the
question
I
have
there
is
exactly
how
fast
sorry,
how?
How
slower
will
that
make
the
page,
because
that
remember
in
the
first
day
in
the
first
couple,
not
what
made
us
move
to
an
asynchronous
rendering
of
the
page
was
exactly
because
the
page
itself
that
was
being
rendered
in
Hamel
took
a
lot
of
time
to
render,
which
is
fair.
If
it's
a
large
file,
if
it's
a
largemr,
it
takes
forever
to
render
the
whole
files
right.
A
B
I
hope
you're
right
because
we
are
skipping
the
whole
loading
JavaScript
executing
JavaScript,
making
a
connection
to
the
server
round
trip
to
the
server
getting
big
data,
pressing
embed
back
rendering
on
the
client.
It
all
takes
a
lot
of
time.
We
just
completely
eliminate
the
step
and
render
it
immediately,
and
so
it
should
be
faster.
I
think
there
is
just
no
way
to
outperform
server
size,
rendering
for
the
first
render
at
least.
B
A
Can
you
partially,
can
you
partially
look
up
the
files
through
giddly
very
quickly
without
having
to
load
the
whole
Mr?
Those
are
back-end
stuff
that
needs
to
be
investigated.
I'm
still
going
to
press
Matt,
I,
don't
wanna
I,
don't
want
to
ignore
what
you
just
said:
I
completely
hear
it,
but
I
still
gonna
push
for
a
potential
Spike
to
investigate
this
on
the
back
ends
of
the
day.
Did
he
no?
He
didn't
right.
So
all
right!
A
This
is
something
that
Natalia
and
the
plant
team
are
investigating
for
making
the
issue
list
labels
filtered
search
faster.
Okay,
are
you
aware
of
this?
Are
you
on
top
of?
Do
you
know
what
this
is
yeah?
Okay,
so
I
can
skip
a
few
things
for
you,
but
for
the
recording.
So
this
is
the
Mr
that
they
currently
are
working
on
and
event.
Essentially,
it
requires
decorating
the
queries
a
little
bit
with
some
with
some
flags
and
stuff
in
this.
A
A
The
only
question
I
have
is
how
useful
is
Persistence
of
stuff,
like
the
merge
request,
widget,
because
that
you
wanted
to
be
fresh
and
that
you
already
have
real
time
built
into
it.
So
if
anything
I
feel
like,
we
could
potentially
look
into
the
user
lookup
this
one
here,
because
it's
like
the
first
one
is
always
the
same
like
it's.
A
The
first
lookup
at
least
that
being
super
Stampy
would
be
your
first
nice
approach
and
then
we
can
build
from
from
then
on,
of
course,
like
if
I
start
writing
a
name
right,
then
it's
super
fast.
So
but
the
first
thing
the
first
lookup
is
where
we
could
probably
benefit
from
something
like
this
across
pages
I.
Don't
think
they're
looking
into
it,
but
eventually
I
think
they
will
get
there
because
issues
are
also
affected.
B
I
imagine
missing
something,
but
I
think
we
we
don't
have
any
any
places
where
we
could
utilize
this,
because
for
the
as
you
described
for
the
merge
request
match
widget,
we
always
want
to
have
the
fresh
State,
because
people
are
constantly
confused
with
our
mesh
widget
like
why
it's
not
merging
or
why
it
doesn't.
Allow
you
to
merge
so
introducing
their
outdated
state
will
make
it
even
more
confusing
yeah
Force
the
autocomplete
you
described,
I
think
it
doesn't
use
graphql
API,
which
is
one
of
the
limitations
of
this.
B
A
B
A
A
B
B
B
I
I
played
locally
with
it
a
little
bit
because
I
was
frustrated
by
this
recently
I
scrambled
through
the
code
it
and
it's
not
straightforward,
because
it
already
has
cash
and
we
basically
have
to
introduce
another
level
of
cash
which
is
like
pre,
pre-caching,
stuff
and
then
properly.
Caching,
these
requests
it.
It
will
make
the
logic
a
lot
more
complex.
So
that's
why
I
created
like
that's
why
this
issues
is
there
because
it
involves
a
lot
more
time
than
I
expected.
Actually,
okay,.
A
A
A
A
Thank
you.
Oh
cash
persist,
persistence,
the
question
and
whether
this
should
also
be
moved
to
graphql
to
benefit
from
that
persistence
came
up.
What
do
you
think?
Do
you
have
thoughts
on
this?
It
doesn't
exclude
making
the
optimizations
for
reusing,
page
relevant
users,
author
reviewers
Etc,
but
if
that
is
to
be
done,
the
work
can
be
planned,
iteratively
ground,
taken
that
into
consideration
to
be
clear.
We
don't
have
any
immediate
plans
to
schedule
this,
so
if
you
so,
if
anybody
wants
to
tackle
this,
go,
feel
free
to
go
ahead.
A
A
B
A
B
B
Count
on
it
because
all
with
all
the
issues
in
gitlab
UI,
please
stop
you,
immigration
to
some
new
version
and
the
base
that
did
not
pure
is
taking
to
update
all
the
stuff,
all
the
broken
stuff
it
might
take
a
while.
So
we
should
really
shouldn't
like
make
a
big
stake
on
the
viewfree
stuff,
okay,
at
least
for
now,
and
work
with
what
we
have.
A
I'm
particularly
interested
in
investigating
the
partial
server-side
rendering
part
and
see
how
we
can
benefit
from
that
realization
that
a
lot
of
our
page,
the
big
bulk
of
data
that
we're
transferring
is
pretty
static.
So,
okay,
it's
been
useful
and
productive
and
that's
that's
it.
Do
you
have
anything
else
to
talk
about?
Can
we
just
edit
here.