►
From YouTube: 2022-11-17 #4 Code Review Performance Round Table
A
And
we're
live
hi.
Everyone
welcome
to
yet
another
performance,
Round
Table
of
the
code
review
group.
Today
it
seems
like
we're
going
to
have
a
front
end.
Only
Round
Table,
that's
totally
fine,
so
starting
off
I'm
going
to
start
reviewing
the
board.
So
last
week
we
had
a
couple:
we
had
a
chat,
a
suggestion
of
using
an
issue
board
to
track
the
the
topics
that
are
being
discussed.
So
this
is
what
it
looks
like
at
the
moment
to
sharing
the
screen.
So
it
should
be.
A
So
these
are
the
topics
that
we
have
right
away,
so
these
two
are
ready
for
development
and
the
first
one
create
technical
documentation
describing
the
several
components
that's
already
being
scheduled
as
a
deliverable
Carey's
already
assigned
Phil
has
already
started
working
on
this,
so
I'm
tempted
to
assign
to
him
in
157
as
well.
We
want
to
finalize
the
plan
later
today,
so
that's
why
we
still
want
to
have
a
face
there,
but
that's
what
I'm
thinking
about
doing
then
there's
the
track.
A
Duration
of
specific
parts
of
this
request,
which
is
back-end
only
so
I,
don't
think
we
can
okay.
So
for
some
reason
this
didn't
make
the
cut.
So
that's
totally
fine,
hopefully
we'll
pick
it
up
soon.
So
we'll
go
through
the
discussions
topics
which
is
this
ones,
the
ones
that
need
refinement.
The
first
one
is
improving
improved
cash
of
the
diff
files
batch
API.
A
That's
a
total
back-end
topic,
so
we're
we're
going
to
skip
that
for
for
now,
as
will
we
do
it
about
with
this
one
as
well,
so
investigate
the
possibility
of
paginating
diff
metadata.
That's
mostly
back-end
restricting
restrictions,
so
we'll
skip
that
too,
whenever
possible,
under
the
mrdfs
from
a
client-side
cache
unless
mrid
is
updated.
So
I
wanted
to
see
if
you
have
any
opinion
on
this,
so
we
had
a
discussion.
I
had
a
question
about
the
security
mentioned
foreign
yeah,
so
this
is
one
of
the
things
that
we
talked
about.
A
Comparisons
with
head
that
don't
cause
any
difference,
differences
in
a
diff.
If
that
makes
sense,
and
then
you
say
I
think
we
can
answer.
Okay,
I
think
we
have
an
answer
for
this.
If
we
can
have
the
metrics,
they
can
give
us
how
much
users
and
how
often
is
the
Mr
changes
in
theory,
we
can
check
requests.
We
need
to
log
in
diff
in
data
I'm,
not
sure
how
this
can
collect
code,
which
we
can.
If
you
can't
include
an
existing
log
entry,
we
can
just
have
a
new
log
engine
that
can
filter.
A
So
what
what
exactly
we
want
to
catch
yeah
so
in
this
Essence
we'll
be
caching
the
rest?
Well,
the
data
that
we're
getting
from
the
batch
diffs
so
in
essence,
and
then
I'm
guessing
this
metadata
too.
So
in
essence,
what
we're
theorizing
is
that
we
can
keep
a
copy
of
those
responses
in
client-side
and
this
could
be
index
CB
so
that
we
can
easily.
A
So
the
reason
why
why
we're
considering
index
CV
is
because
we
need
to
be
able
to
quickly
check
how
many
Mr
copies
do
we
have
older
than
seven
days,
for
example,
and
Destroy
them
that's
one
of
them
for
clashing
for
caching,
validation
and,
and
the
other
is
just
to
be
able
to
specifically
grab
certain
parts
of
data.
If
we
want
to
keep
it
in
local
storage,
we're
going
to
have
to
you
know,
un
to
parse
the
Json
that
is
kept
in
local
storage.
Read
it
check
it
all
right.
A
B
A
A
B
B
B
B
I'm
not
sure
I'm,
not
sure
that
HTTP
guessing
is
really
working,
even
though
we
are
getting
like
three
or
four
yeah
cold,
we're
still
waiting
like
for
500
milliseconds,
which
basically
takes
the
same
amount
as
to
get
the
fresh
request
without
any
guessing.
So
it
doesn't
seem
like
it's
doing
anything
at
least
now,
because
if
we,
if
it
was
cached,
we
should
see
no
response
time.
It
should
be
just
written
as
like
in
memory
cache
or
like
local
cache.
Whatever.
A
A
B
A
A
Move
on
yep
yeah
right
thanks
for
that.
That
brings
us
to
Virtual
schooler
that
I
have
somewhere.
Here
we
go
right:
virtual
school,
we
talked
a
little
bit
about
aesthetic
under
being
rendered
client
side
that
we
don't.
That
has
never
changed.
Look
we
need
so
we're
looking
into
rendering
in
a
worker
and
then
I
asked.
A
B
Yeah
I
had
some
progress.
Exploring
this
so
basically,
I
have
a
working
demo,
which
is
rendering
this
app
using
u3
compact
mode
and
also
working
them
up
of
rendering
our
divs
only
in
web
worker
I'll
try
to
show
you
how
it
works
right
now.
Basically,
it's
just
this:
it's
not
any
other
stuff,
it's
not
discussions,
extending
clients
or
whatever
sure,
basically,
no
interactivity,
but
it's
it's
working
already
in
in
a
very
primitive
form.
So
let
me
share
the
screen.
A
B
B
A
B
B
B
B
B
B
It's
basically
instant,
so
once
you
render
it's
completely,
it
is
really
fast
and
also,
as
you
can
see,
the
memory
is
not
growing.
So
it's
constantly
fixed
at
the
position,
which
is
a
good
thing
right.
It
might
be
also
related
to
to
the
to
the
stuff
from
the
previous
run,
so
it
might
not
be
just
cleared.
A
B
B
A
B
B
So
I
plan
to
instigate,
like
the
coupling
static
and
dynamic
content,
to
see
how
it
works
sure
does
it
make
sense.
I
also
found
a
lot
of
caveats
regarding
this
approach.
For
example,
we
cannot
use
style
tag
in
sfcs
in
vsfc.
So
if
you
want
to
render
this
at
least
now,
because
it
tries
to
inject
Styles
into
head-
which
we
don't
have
in
worker-
basically
crashes
right-
and
there
are
many
many
more
other
stuff
that
that
I
can
list
forever.
B
B
I
think
we
should
look
a
little
bit
more
into
server-side,
rendering
all
the
stuff,
okay,
I,
suppose
it
was
used
to
be
seriously
rendered
and
did
moved
to
client-side
I'm,
not
sure
yes,
so
if
we
had
this
client
server
side
rendered,
we
can
actually
combine
these
approaches.
So
we
can
fetch
the
service
that
render
stuff
rendered.
B
So
if
we
can
get
the
stuff
search
that
rendered
and
fetch
it
from
the
server
and
especially
if
it's
cached
already
yeah,
that
would
be
much
faster
than
the
working
the
worker
solution,
because
the
worker
has
to
spin
up.
It
also
has
a
completely
different
bundle,
which
also
takes
them
to
parse
to
compile
right.
A
Especially
for
the
first
paint,
if
it's
yes,
if
it's
just
the
deaths,
the
diff
lines,
there's
I
mean
we
always
try
to
not
repeat
ourselves
right
but
I
wonder
if
we
could
get
a
prototype
built
with
with
rails
template
with
handle
template.
We
can
just
code
what
we
have
in
use
Hamel
to
generate
those
server-side
rendered
for
now.
A
So
the
downside
of
that
is
that
we
won't
be
able
to
update
it
in
one
place
and
then
have
it
be
reflected
everywhere.
But
if
we
can
just
use
that
for
the
diffs
contents
and
generate
that
on
the
back
end
now
we
still
need
to
batch
it
to
the
to
batch
it
for
the
front
end.
The
reason
why
we
moved
away
from
the
server
side,
rendering
in
the
past
was
exactly
the
page
was
taking.
A
You
know
30
seconds
and
minutes
to
render
to
even
render
the
first
render
the
first
byte,
because
everything
was
being
computed
in
the
back
end.
So
so,
if
we
could
give
it
a
test
of
like
how
would
it
look
like
in
a
way
that
we
can
still
work
with
it
in
the
front?
End
could
be
interesting
to
give
it.
B
We're
not
necessarily
like
into
budget.
We
need
to
do
just
one
request,
so
basically,
the
rendering
stuff
could
be
split
into
two
parts.
The
one
part
is
rendering
like
first
five
files
on
server,
which
should
shouldn't
take
a
lot
and
the
user
immediately
gets
rendered
this
without
any
spinners
without
any
additional
loading
of
client-side
code.
A
B
I
have
to
look
into
what
we
are
exactly
heading
inside
Json,
because
it's
not
just
clients
like
highlighted
lines.
It's
also
like
robot
coverage,
yeah
and
lots
of
other
stuff.
So
I
guess
we'll
still
have
to
request
this
stuff.
But
the
good
thing
is
that
now
we
can
decouple
this
so
sure
the
lands
themselves
decoupled
from
the
metadata
they
have
like
from
the
code
coverage
discussions.
At
least
we
can
see
all
the
code
and
render
all
the
stuff
on
top
of
this,
but
we
already.
A
A
Got
it
right,
we
would
be
interesting
to
see
how
that
could
work.
So
I'm
writing
a
comment
here,
so
you
can
so
I
missed
some
music
I
make
I.
Miss
I
missed
some
of
your
next
next
steps
and
I
added
some
caveats
there.
We
need
to
make
it
faster,
that's
with
HTTP
caching
what
if
we
could
catch
the
output
of
the
rendered
worker
in
the
client
and
some
caveats.
A
A
B
A
A
A
Anything
yeah,
so
we
want
to
catch
that
and
update
the
the
markup
and
stuff,
but
it
shouldn't
be
too
different.
I
think
once
we
get
to
the
line,
that's
just
the
highlighted
line
that
we
get
from
I,
don't
know
Rouge
or
something
so
yeah
could
be
interesting
to
chat
test
that
out.
So
should
we
call
it
there
share
it
here.
What
was
the
next
steps?
Can
you
just
help
me
fill
this
in
I
was
running
these
questions,
testing
inline.
In
parallel,
there
was
something.
B
B
B
A
B
A
B
A
I
think
this
is
a
no-brainer
in
terms
of
like
gains
right.
If
we
have
merge
requests
with
these
files
that
are
not
necessary
great,
we
can
suppress
them,
but
I
think
this
is
mostly
like
backhand,
because
the
backend
is
to
detect
them
and
they
need
to
not
send
them
in
the
payload
or
whatever
and
then
offer
a
way
to
reload,
which
we
already
have
I.
Think
with
a
given
the
path
so
yeah
and
there's
that
much
here
for
me
to
think
about
is
more
like
backend
wise.
Is
this
feasible?
B
I
think
the
question
is:
if
we
cut
anything
from
the
API,
does
it
really
improve
the
performance
of
that
API?
Because
it
seems
like
it's
not
the
amount
of
data
we
send
it's
the
amount
of
calls
we
do
and
I
don't
think
we
we
can
avoid
calls
to
like
facing
the
diff
itself
from
the
API.
It
doesn't
remove
that
call
right.
So,
even
if
it
has
the
data
I'm,
not
sure
if
it
can
actually
improve
the
performance
of
the
API,
but
we
have
to
ask
for
backend
here.
A
Yeah
of
the
responses
would
improve
significantly
because
it
doesn't
seem
like
the
problem.
Let
me
share
the
screen,
so
you
see
what
I'm
writing
to
see
if
I'm,
reflecting
what
you
said
well
seem
like
we're
being
slow
on
the
transmission
that
we
are
being
slow
in
the
queries
we
do,
yeah
suppressing
would
remove
them.
A
A
B
A
Also,
a
relevant
topic
is
the
possibility
of
suicide,
rendering
server
side,
rendering
parts
of
the
diff
see
there.
Okay,
all
right,
I
think
it's
good,
so
yeah
now
the
agenda
is
empty.
If
we
didn't
say
anything.
So
let
me
just
right
here
we
revised
so
I
know
what
I'll
do
so.
I'll
just
copy
this,
because
that
discuss
that
and
we
discussed
that.
A
A
B
A
Kind
of
our
little
performance
focused
one-on-one,
yeah,
I,
appreciate
it.
Let's
keep
the
ball
rolling
I'll
open
a
new
issue
for
the
next
week
and
I'm
also
going
to
check
about
the
time
if
you
can
make
it
in
a
way
that
we
have
more
backend
available
to
to
join
the
call
I
think
if
it
bit
early,
we
could
probably
include
David,
so
I
want
to
see
yeah
it's
it's
seven
already
for
him,
so
yeah
I'll
I'll
get
the
ball
rolling
on
that.
Thank
you.