►
From YouTube: 2022-11-24 #5 Code Review Performance Round Table
A
A
A
It's
not
a
problem
per
se,
but
just
something
for
us
to
be
aware
of
that.
We
need
to
follow
the
issues
and
have
the
discussions
evolving
issues
themselves,
not
an
issue.
Just
the
heads
up,
so
the
first
topic
we
have
open
still
to
be
discussed
is
the
improved
caching
of
div
files.
Batch
API
there's
been
some
some
movement
there.
Is
anybody
aware
of
updates,
or
is
this
just
purely
back
in.
B
C
D
D
I've
checked
that
and
the
caching
doesn't
work
really
well
for
us
at
now.
Right
now,
it's
on
production,
at
least
so
I
will
create
a
like
an
improved
version
of
that
and
see
if
that
works,
because
right
now
we
have
to
invalidate
our
caching
hash
on
the
backend
side
and
it
seems
to
not
work
so
I'll
try
to
push
this
caching
key
to
the
front
end.
So
it's
strictly
cached
on
the
front-end
side,
without
touching
backhand
at
all
and
we'll
see
what
it
gives
us.
D
A
A
Happening
in
a
related
top
paper
and
I'll
put
the
link
in
there
so
that
people
can
follow
me
with
that
discussion.
Exactly
whether
you
and
Patrick
were
having
sounds
good
feels
like
we
definitely
want
to
make
sure
that
we
can
Leverage
The.
Caching
with
that,
be
the
easiest
way
to
make
sure
that
the
HTTP
caching
would
be
working
well,
and
if
we
move
it
to
the
hash,
sorry,
the
URL,
then
it
would
definitely
be
easier
to
make
that
happen.
So
yeah
keep
pushing
that.
D
Also
so
discussion
on
the
backend
side
that
they
want
to
basically
before
doing
any
preemptive
caching
on
radius
or
anywhere
else
they
want
to
measure
what
takes
the
most
time
for
our
gifs
file
bash
API
to
get
there
to
get
the
result,
so
they
want
to
measure
it
first
and
then
apply
any
optimizations
or
caching
strategies.
So
that's
what
I've
heard
from
them,
foreign.
A
Working
on
with
Gary
is
mapping
out
the
whole
system
and
part
of
the
ask
that
we
had
that
we
did
was
to
get
some
timings
like
rough
timings
for
each
component
like
where
are
we
taking
longer
I
think
we
can
get
a
good
first
hint
of
delays
out
of
the
I
want
to
say
flame
graph
that
they
have.
So
we
might
be
able
to
take
a
couple
of
of
good
hints
on
on
those
metrics,
but
we
might.
They
might
want
to
dig
deeper
on
certain
things
that
are
not
shown
on
the
plane
graph.
A
So
awesome,
especially
synchronous
work
and
everything
so
I
don't
know
yeah.
Let's
have
them
forward
they're,
not
here,
so
we
can
get
any
more
updates,
but
hopefully,
hopefully,
through
the
next
week,
we
can
get
some
updates
on
the
back
end,
yeah,
okay,
so
moving
on
to
the
next
point,
then
we
don't
have
to
linger
too
much
here,
investigate
the
possibility
of
paginating
GIF
metadata.
There's
been
some
movement
here
as
well.
A
D
Patrick
suggested
a
really
good
idea,
splitting
metadata
and
file
tree,
which
takes
most
of
the
time
for
a
big
mess,
request
yeah,
and
he
made
actually
a
working
proof
of
concept
already
that
they
can
use.
So
he
splits
file
3
into
a
separate
API,
and
it's
also
pigeonatable.
He.
He
told
me
that
it
yeah
it
takes
about
100
milliseconds
to
get
the
first
30
items
which
is
really
good.
So
we
could
use
that
to
show
the
file
tree
first
and
then
load
metadata
as
soon
as
it's
ready.
D
That
way,
we
can
show
stuff
independent
of
each
other.
We
won't
be
dependent,
metadata,
won't,
be
dependent
on
file
3
and
file.
3
won't
be
dependent
on
metadata.
It's
sold
in
parallel,
so
set
should
be
like
a
nice
performance
Improvement
for
us
and
I'll
play
with
it
around
to
see
if
it
can
actually
improve
the
perceived
performance.
A
A
A
What
I'm
thinking
here
is
we
have
an
issue
in
the
pipeline
to
only
load
the
single
file
if
you're,
following
the
link
to
a
discussion
right.
So
all
of
these
different
ways
of
loading
data
is
just
a
mess
at
this
point,
but
it
is
a
mess
that
is
introducing
some
improvement,
so
I'll
I'll
allow
it
I
guess
but
I
think
I
agree,
but
yeah
I
think
I
think
at
a
certain
point,
we
need
to
step
back
and
make
it
more
robust.
A
I,
don't
know
if
it's
moving
to
refuel
and
letting
the
front
end
kind
of
dictate
how
we
load
this
data
or
or
something
else,
but
we
might
want
to
make
like
whether
it's
a
service
like
a
local
front-end
service
that
is
more
responsible
kind
of
like
just
get
the
data
in
the
appropriate
way
in
the
the
app
is
simplified
by
that.
So
we'll
have
to
think
about
that
later,
but
for
now
I
think
this
is
a
good
way
to
get
some
gains
in
there.
B
A
Right
thanks
yeah.
Definitely
that's
Mutual.
He
begs
the
question
whether
the
metadata
is
used
elsewhere,
but
I
didn't
think
so.
The
the
file
on
the
metadata
I
don't
think
we
are
and
we
can
save
some
some
time
on
it.
Yeah
great
yeah,
baby,
I,
don't
think
we
are
because
we,
the
diffs
the
diff
files
on
the
batch,
is
the
one
we
use
to
run
the
the
content,
but.
B
A
Is
it
I,
don't
know
if
that's
the
one
anyway,
regardless
of
what
it
is,
we
can
definitely
make
that
split
into
a
separate
file
called
a
good
effort,
separate,
call
and
we'll
go
from
there,
but
yeah
something
to
keep
an
eye
out
for
right.
Next,
one
I
think
we
almost
almost
already
covered
this
one
like
whenever
possible,
random,
DMR
dips,
client
side,
the
cash
write
a
name
or
ID,
and
this
has
been
like
the
last
week.
A
B
Oh
so
we're
cashing
with
the
e-tag
stuff.
Why
don't
we
just
dumping
into
redness
and
now
I
know
you're
going
to
see
because
we
use
too
much
redness,
but
like?
Can
we
not
just
done
more
into
register
me
just
give
us
more,
you
know
stuff
in
the
back
getting
side
of
things
like
it
seems
kind
of
bad,
though
we
could
make
it
better
for
everyone,
but
we're
kind
of
being
held
up
biting
Bishop,
chair.
D
D
A
B
A
C
D
I
also
think
that
one
of
the
reasons
again,
this
quite
hesitant
to
move
this
into
radius
is
because
we
are
already
caching,
quite
a
lot
of
like
stuff
in
registered
already
like
I
think
they
they
are
caching
the
diff
itself
in
radius,
and
on
top
of
that
we
add
caching
of
the
response
that
we
request
on
the
client
side.
So
it's
essentially
it's
doubling
the
size
of
the
cache,
at
least
doubling.
D
A
Yeah
I
I've
been
even
thinking
about
using
different
storage,
different
caching
storage,
and
so,
if
you
think
about
all
the
all
the
static
stuff
on
the
merger
Christ,
if
we
had
an
object
like
say
an
S3
bucket
with
all
the
Json
responses
for
every
every
Mr
that
doesn't
change
until
there's
a
commit,
we
could
generate
those
files
upon
the
submission
of
the
commit
upon
the
creation
of
a
diversion
you
generate
immediately.
The
files
put
them
in
a
static,
storage
and
basically
rails
would
only
have
to
read
the
files
right.
A
It
wouldn't
be:
a
storage
in
cash.
It
wouldn't
be
a
storage
in
in
redis,
but
it
would
be
a
storage
in
like
some
file
systems
somewhere,
and
that
tends
to
be
fast.
It's
not
probably
as
fast
as
radixes
in
memory.
But
you
remove
a
lot
of
the
competition
because
then
then
we
won't
have
the
problem
of
in-memory
caching.
D
We
need
like
memory.
So
that
was
my
idea
and
methodonts.
Second,
didn't
really:
it
wasn't
really
sold
on
them
because
they
need
to
investigate
this
more.
They
need
some
data
like
analytics.
What
what
are
the
heaviest?
My
requests?
What
are
the
three
most
frequent
requests?
We
do
they
need
some
data
and
that
is
reasonable
and
I.
Think
we
at
least
I
don't
have
the
data
on
my
hands
right
now.
A
Yeah,
let's
keep
talking
about
it
and
hopefully
we'll
get
some
back-end
folks.
There
then
look
deeper
into
that
or
just
explain
a
little
bit
more
cool
on
to
the
next
point:
virtual
scroller
that
or
basically
alternatives
to
wrote
a
virtual
scroller
and
Santa's
love.
Do
you
have
a
bit
of
an
update
for
us.
C
C
D
D
D
So
I
will
continue
to
push
this
forward
to
see
how
how
complex
it
is
to
add
discussions
on
top
of
this
static
rendered
divs,
because
right
now
we
render
discussions
the
same
way.
So
we
render
divs
first
and
then
our
discussions
on
top,
but
it's
all
done
in
The
View
application
I
would
like
to
separate
system
applications.
So
discussions
will
be
a
separate
application
from
the
divs
I'll
see
how
how
that
affects
performance?
How
how
hard
is
it
to
tick,
Apple,
actually
and
we'll
see
and
and
I'll
make
some
measurements?
D
I
guess
compare
all
our
current
Solutions,
like
virtual
scrolling,
the
worker
stuff
and
if
I,
if
I,
have
a
chance
compared
to
server
side
rental
divs,
because
we
have
a
series
that
render
diffs
already
on
the
like
commits
page.
When
you
view
a
specific
commit
and
all
the
files
it
render
them
on
the
server.
We
can
reuse
that
to
at.
C
D
A
A
Sorry,
let
me
ask
this
first,
so
you
said
that
trying
to
make
a
separate
application
for
the
discussions
separate
from
the
diffs.
So
how
does
that
relate
to
the
fact
that
we
already
have
two
View
apps
the
nodes
and
the
dips?
They
both
share
the
notes.
Would
you
extract
the
notes
from
those
two
apps
and
have
a
separate
app
to
handle
the
notes
and
then
talk
to
both
the
diffs
and
the
notes?
The
overview
tab
so
to
speak.
D
Okay,
if
it
starts
them
in
the
ux,
it
doesn't
really
matter
because
we
just
pre-use
the
same
store.
The
important
thing
is
like
how
we
Mount
these
applications,
how
we
like
add
them
to
the
Zone.
This
is
the
important
part,
because
we
cannot
add
the
discussion
until
we
fetch
the
required
line
like
we
if
the
land
is
not
in
the
Dom.
Yet
we
cannot
add
the
discussion
to
that
line.
We
should
handle
that
and
also
should
handle
adding
new
discussions
to
the
statically
rendered
divs.
A
Remember,
there's
discussions
in
divs
there's
discussions
that
are
non-indicts,
so
theoretically,
you
could
enter
the
discussions
that
are
not
in
depths
right
away
and
wait
for
the
divs
to
be
loaded
yeah.
We
can
turn
it
on.
Let's
begin,
okay,
I
had
another
question.
Yeah.
You
said
that
it
wasn't
you.
You
only
had
the
deaf
ones.
You
didn't
have
a
lot
of
interaction
yet
on
the
demo.
A
Not
new
functions
well,
I'm,
not
not
to
worry
about
the
new
functions
or
extending
features,
and
something
like
that.
It's
more
like
right
now
we
have
a
dump
of
HTML
on
the
page,
great
yeah,
but
now
we
need
to
make
all
the
interactions
like
leaving
a
comments,
adding
code
quality,
stuff
yeah.
Will
we
be
able
to
continue
to
use
a
view
for
that
for
those
interactions,
yeah.
D
Yeah
we
can,
we
can
use
you
view
for
that,
I'm,
not
sure
how,
because
I'm
not
I'm,
not
sure
how
like
code
quality
works.
It
just
starts
in
the
amount
of
hook
and
what
it
does
I'm,
not
sure
we
certainly
will
have
to
extract
all
the
interactive
components
into
separate
apps
like
the
line
expansion,
discussions,
diff
header
that
collapses
or
marks
as
viewed
you.
D
D
A
That's
exciting
I
want
to
see
that
I
want
to
see
how
we
solve
that
for
sure,
but
that's
a
little
bit
ahead
of
now.
Let's
keep
pushing
on
the
on
the
front
that,
like
most
immediately,
is
exactly
like.
How
do
we
service
at
random
parts
of
this
I
wanted
to
add,
like
I'm,
okay,
in
repeating
ourselves
here?
If
we
have
to
copy
the
code
that
we
have
in
a
view,
template
or
or
HTML
piece
move
it
into
Hamel
and
duplicate
that
code,
a
little
bit
I'm?
A
Okay
with
that,
because
it's
so
performance
work,
I,
guess
so
yeah,
let's,
let's
try
it
out
and
see.
If
we
can
do
this
fast
enough
to
be
worth
it,
I
mean
and
yeah
I'm
happy
to
just
leverage
rail
that
we
have
it
right
now
and
then
we
can
look
for
other
options
later,
but
for
now
this
will
be
a
nice
try
cool
any
other
thought
any
any
other
thoughts
there.
A
D
C
A
A
A
A
A
Just
a
heads
up,
I
will
be
out
of
office
next
week
and
the
following
week.
So
the
next
two
weeks
I'll
be
out
of
office.
It's
a
holiday
here
in
Portugal,
so
I
will
find
someone
to
make
sure
that
the
meeting
happens
and
the
documents
get
updated
and
that
sort
of
thing
so
but
I
won't
be
here.
So
please
carry
these
on
push
the
efforts
forward
as
if
I
was
here
right
and
with
that.
Thank
you.
So
much
have
a
wonderful
weekend
and
I'll
see
you
next
week.