►
From YouTube: 2023-03-09 Code Review 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).
B
B
So
what
it
does
it
takes
a
div
file
by
file,
then
it
renders
its
like
in
an
invisible
state
to
get
its
height
and
it
populates
the
height
for
HD
file.
That
way
it
can
calculate
the
heights
over
time,
but
the
problem
is
that
is
thread
blocking
so,
for
example,
if
you
have
200
files,
you'll
have
to
calculate
the
height
for
all
of
these
200
files
in
order
to
get
a
proper
scroll
height,
and
it's
the
main
problem
with
our
page
right
now
in
terms
of
performance.
B
B
The
problem
is
that
light.
Wrapping
is
quite
hard
to
do
so.
I've
mentioned
in
the
agenda
that
Kai
said.
We
won't
do
this
because
recently
we've
tried
to
implement
a
simple
solution
to
that,
which
is
to
like
just
basically
disable
it
and
show
scroll,
and
it
didn't
quite
work
because
it
has
many
issues
and
I've
linked
in
the
in
the
proposal.
I've
linked
and
layout
refactoring
issue
by
Andrea,
which
basically
lists
all
the
problems
with
that.
B
But
I
think
we
should
reconsider
that
because
it
provides
both
performance
improvements
and
language
of
second
of
all
people
are
actually
voting.
This
feature
there
are
people
who
would
like
to
see
us
having
a
non-wrapping
mode,
so
I
think
it's
it's
kind
of
Worth
to
get
back
to
this,
not
to
cancel
it
so
per
the
time
being.
B
So
that's
the
proposal
and
it's
we
still
were
discussing
because
even
if
you
don't
don't
decide
to
stay
with
virtual
scrolling,
which
we
always
consider
like
an
intermediary
step
to
a
better
solution
for
rendering,
for
example,
if
you
go
over
server
side
rendering
it's
still
beneficial,
because
it
also
can
get
the
same
performance
improvements
from
this,
for
example
with
content
visibility,
which
basically
works
very
closely
to
what
virtual
scrolling
does.
So,
it's
always
beneficial,
no
matter
what
solution
we
decide
to
use
for
for
our
this
app.
B
Let
me
see
Okay
so
I
have
chat,
brain's
IDE
here,
for
example,
let
me
find
a
bigger
tube,
so
right
now
I
don't
have
line
wrapping
enabled.
So
you
see
the
soft
wrap
it
actually
wraps.
The
lens
I
can
disable
it
and
see
the
whole
length
without
ripping
and
notice
when
I
start
scrolling,
it
actually
synchronizes
scrolling
for
me
so
synchronizing
both
directions
if
I
scroll
horizontally
or
vertically,
it's
always
on
the
same
line.
So
we
could
work
with
something
like
that
and
I.
B
A
C
Yeah
on
hi
everyone,
so
the
issue
that
is,
that
is
to
support
the
multitude
of
possibilities
like
to
have
the
soft
traps
to
have
to
not
have
the
soft
trap
to
have
the
inline
to
have
parallel.
All
of
that
in
conjunction
in
the
ux
difficulties
we
had
was
right
now
on
the
example
that
sellers
love
showed.
C
So
and
that's
those
are
the
challenges
that
kind
of
like
it's
really
tricky,
to
implement
all
the
variations,
all
the
and
cover
all
the
ux
big
Force.
This
is
able
to
send
this
level
is
a
really
good
of
going
around
horizontal
scrolling
on
the
two
sides
of
the
parallel
you
step
with
something
we
would
consider,
but
for
us
to
be
able
to
implement
that
it's
kind
of
like
a
bit
more
tricky
to
get
to
that,
because
of
the
way
that.
C
B
Yeah
I've
described
that
it
basically
solves
the
main
problem
with
our
chips
up
rendering,
which
is
like
the
current
set
speed
by
plan,
gives
that
we
have
like
five
seconds
of
total
blocking
time
with
this
change
enabled
and
let's,
let's
imagine
we
have
no
discussions,
also
div,
it
shouldn't
be
five
seconds.
It
should
be
like
200
or
300
milliseconds,
so
the
changes
actually
substantial
to
the
performance.
B
B
C
C
Yeah
we're
not
saying
no
we're
just
saying
that
for
us
to
do
that,
we'll
have
to
first
repurpose
the
layout
to
be
much
more.
You
know
robust
and
malleable,
and
it's
about
the
trade-off
of
cost
of
implementation
versus
the
benefit
and,
of
course,
I
can
understand
the
cost
of
that
and
yeah.
We
will
discussing
this
for
a
while,
and
it
feels
like
virtual
scrolling
was
always
a
patch.
It
was
a
Band-Aid.
C
It
doesn't
mean
that
we
can't
play
around
with
it
in
a
POC
perspective,
but
I
I'm,
very
doubtful
that
we
will
be
able
to.
You
know
pick
it
up
such
a
refactor
for
the
layout
of
the
diffs.
Unless,
for
example,
we
have
again
because
remember,
we
always
always
have
to
support
the
system
where
we
don't
have
the
rep
lines,
and
it
will
be
you'll,
be
safe
to
assume
that
the
majority
of
the
users
would
use
what
we
have
today.
C
So
it
feels
like
it's
such
a
task
to
build
this
for
a
again
I
understand
the
performance
benefit
for
sure
if
we
can
determine
the
height,
even
if
we
use
Rams
for
accountability
for
the
for
the
accessibility
perspective
of
users
having
a
different
line
height.
Even
if
you
did
all
that,
we
will
still
have
to
support
the
other,
and
that
would
still
be
the
major
part
of
the
users
using
that,
so
it
doesn't
solve
a
problem
for
all
users
so
but
yeah.
C
A
C
Poc
kind
of
thing
we
build
a
boc
for
this
and
just
to
see
the
performance
of
improvement,
or
we
use
right
the
Phil's
brexit
to
assess
the
performance
improvements.
Or
should
we
focus
our
attention
into
you
know
not
needing
a
virtual
scrolling
or
because
all
the
other
proposals
that
we
have
on
the
table
like.
A
A
B
Yes,
why
I
don't
have
a
better
like
an
alternative
solution
that
can
reach
everyone
even
like
if
we
disable
virtual
scrolling
completely
and
decide
to
server-side
render,
we
will
still
be
met
with
the
same
problem,
because
we'll
still
have
to
render
all
this
stuff
on
the
client
which
is
problematic
and
which
is
something
I've
already
also
encountered
in
on
the
blame
page,
which
has
streaming
support
so
yeah.
If,
if
we
could
at
least
find
some
solutions
that
has
the
best
reach
out
of
every
Solutions,
that
would
be
great
yeah.
C
I,
remember
those
proposals,
I,
remember
those
proposals,
you
you
did
that
proposal
you
did
to
you
know
when
you're
following
a
link
prioritize
the
render
of
that
file.
Put
that
in
the
top
of
the
file
like
those
kinds
of
things
to
me,
and
then
we
just
continue
rendering
as
we
go,
and
if
we
can
find
a
way
to
remove
the
overhead
of
rendering
each
line
or
rendering
each
div
we
can
remove
the
overhead
of
all
the
listeners.
C
That
view
sets-
and
we
just
use
different
way
to
put
it
on
the
page
I
feel
like
I
feel
like
we
will
have
that
reach.
It
will
have
that
because
again,
we've
seen
it's
not
just
the
layout
effort
that
is
causing
the
problems.
It's
the
overhead
of
JavaScript
listeners
and
it
feels
like
we
can
put
things
on
the
page.
It's
just
that
everything
everywhere
all
at
once
is
ready
to
be
reactive
anyway.
C
I,
don't
think
it's
worth
lingering
too
much
on
this
point,
but
I'm
I'm,
okay
in
like
dedicating
some
time
to
kind
finding
the
timings
of
this.
Knowing
that
It's
tricky
to
invest
too
much
time
implementing
it
right
now
and
say,
we
came
back
with
numbers
that
showed
that
that
view
with
the
fixed
line
high
with
the
wrapping
with
the
non-wrapping
lines,
we'll
get
a
benefit
of
like
70
of
speed,
I.
C
B
I
I'll
also
quickly
mention
I,
think
there
might
be
a
correlation
between
measure,
Quest
size
and
people
wanting
to
use
an
unwrapped
mode.
I
think
there's
a
correlation
between
that,
because
some
languages
force
you
to
make
bigger
Mrs
and
usually
these
are
the
languages
that
have
very
long
clients,
so
I
think
we
could
shoot
to
rabbits
with
one
shot.
Is
that.
C
A
Yeah
sure
yeah
for
the
next
point,
it's
regarding
the
tips
patch
cache
with
max
age,
feature
effect.
So
changes
are
done
and
the
back
end
front
end.
So
we
should
already
throw
it
out,
but
I'm
just
wondering
like
what,
if
we
tested
within
our
team,
like
maybe
have
a
project
in
Tessa,
memrs,
commenting
or
whatever
rebase
and
something
else
see
if
they
could
there's
a
bug
with
still
caching
I'm
hoping
there's
done,
based
on
my
based
on
my
testing.
B
B
C
C
Merge
request
for
watching
for
the
merger
Quest
large,
just
take
a
look
real,
quick,
it's
in
the
git
level
or
gitlab
project
right.
So
if
we
change
the
feature
flag
for
that
project,
this
dashboard-
or
this
test
will
will
display
that
and
we'll
be
able
to
see
the
impact
that
it
has
on
this
metrics
and
then
again
we
will
have
the
recording.
So
we
can
watch
the
recording
there
of
the
difference
now.
The
question
is:
would
it
benefit
this
test.
B
C
Tools,
but
if
anything,
yeah
defined
bugs
yeah
I
as
long
as
we
enable
it
in
the
morning
for
us
where
some
of
us
will
be
around
to
catch
like
if
anything's
wrong,
we
just
turn
it
off
immediately.
I
wouldn't
I'll,
be
fighting
like
speeding
up
the
rollout
going
directly
to
the
guitar
work
gitlab
project
and
watching
the
watching
it
and
dropping
a
line
on
on
the
what's
happening
in
GitHub
slack
channel.
So
in
case
somebody
picks
up
issues
they
cover.
C
C
C
B
B
A
Yeah,
that's
good,
yes,
I!
Think
it's
going
to
be
less
disruptive
too,
because
usually
we
just
enable
it
on
GitHub
or
www.pipta.com.
Then
sometimes
it
affects
the
workflow
of
people,
so
yeah
I
guess
we
can
use
I
think
we
can
use
those
projects.
So
we
have
a
wider,
a
wider
base
and
then
yeah
just
wait
for
feedback.
C
A
C
Right,
no
100,
and
if
it
if
something
goes
wrong
with
the
ID,
just
turn
off
the
feature
flag,
and
then
we
can
schedule
the
fix
for
the
next
master
or
something,
but
it
is
important
to
start
rolling
it
out
so
that
we
can
like
get
some
lessons
from
it.
I
don't
expect
us
to
be
able
to
turn
it
on
by
default
in
this
Milestone.
C
C
A
Yeah
the
next
points
just
an
FYI,
so
so
we
had
already
cash
per
discussion
before
and
it
would
replace
it
with
HTTP
caching,
but
so
it's
still
behind
the
feature
flag,
but
it's
enable
the
production.
So
it's
disabled,
the
research,
disabled.
Everything
is
super
caching,
so
there's
no
still
real
effect,
there's
no
difference,
but
on
the
GPT
test,
there's
a
difference
because
how
the
test
behaves
so
there's
a
discussion
in
that
link
that
I
posted
in
the
agenda
that
foreign
crashes
thoughts
for
discussions
endpoint
it's
spending
around
like
2.5
seconds.
A
So
yeah,
so
that's
going
to
be
an
ns2
against
the
performance
issue
which
is
going
to
be
a
back-end
issue,
so
we
need
to.
We
need
to
look
at
look
into
it,
so
if
we
can
improve
it
further
so
far
we
look
into
paginating
it.
So
it
helps
it
help
a
bit
but
yeah
still
slow.
So
there's,
maybe
something
in
there.
That
needs
to
be
fixing
because
I
think
2.5
seconds
a
long
time
for,
like
a
paginated
result.
A
We
disabled
the
red
discussion
because
it's
causing
too
much
storage
on
production
and
it's
not
really
being
used.
The
utilizations
like
it's
really
low,
then
for
I
can't
remember
the
exact
configured,
but
right
now,
based
on
the
I,
have
a
visualization
of
like
cash
results
versus
cache
results.
It's
like
only
20
percent
of
the
requests
are
being
cache,
so
most
of
the
time
like
users
are
viewing
the
discussion
refresh
so
is.
B
B
B
This
must
be
the
reason
why
it's
having
low
utilization,
because,
like
I,
can
I
can
see
how,
like
a
person,
asks
comments
to
the
image
request
and
then
and
after
wants
to
reply.
But
in
order
to
reply
he
has
to
choose
a
page
and
it's
not
cached
for
him
for
his
first
visit
so
yeah.
Does
that
make
sense.
A
C
A
C
We
don't
have
the
the
caching
effort
we're
doing
is
on
the
batch
diffs,
the
ones
above
the
max
age.
We
don't
have
that
for
the
discussions.
Will
that
will
that
apply?
Should
we
should
we
work
on
that
and
even
then,
if
we
do,
we
won't
fix
the
problem
of
the
metrics.
So
we
still
have
the
report.
The
severity
too
So
when
you
say,
replace
with
HTTP
caching.
A
A
C
A
C
I
would
be
okay
having
a
separate,
so
whenever
we
track
the
metrics
of
the
sort
of
thing,
I'll
be
okay
on
having
a
secondary
result
that
would
show
like
old
cash
worm
cash
yeah,
because
it's
important
to
understand
the
two
scenarios
because,
like
you
said
not
every
visit
to
the
pages
were
so
this
world
cache.
So
thanks.
C
B
A
B
C
C
B
C
Okay,
so
right
we
can't.
We
can't
do
the
this.
The
assumption
that
the
last
comment
being
loaded
on
the
last
page
is
the
last
being
shown
because
it
could
be
the
first
one
on
the
first
line
on
the
first
file
and
if
you're
downloading,
if
you're
navigating
the
changes,
then
it
becomes
there's
one
again.
C
I
I
might
be
the
only
one
hammering
on
this,
but
there's
one
scenario
that
I
think
we
could.
So
if
you
go
into
the
changes
tab
and
you
have
file
by
file
mode
enabled,
we
could
have
an
endpoint
to
load
the
discussions
for
for
a
single
file.
Only
we
don't
have
that
at
the
moment.
I
think
we
just
load
per
page,
but
then
we
go
back
to
that
thing.
That
would
only
benefit
those
users
and
we're
not
even
testing
that
scenario
the
file
by
file
mode,
but
yeah
thanks.
B
I'll,
just
I'll
delete
last
point
that
I
think
having
floating
discussions
that
are
not
affecting
the
high
positive
might
help
with
that,
because,
if
H
just
the
lines
set
having
that
that
have
discussions,
which
should
be
I,
think
faster
than
fetching
the
whole
discussion
content.
If
you
have
just
this
information
which
files
and
which
lines
have
discussions,
we
could
show
some
kind
of
indication
that
this
line
has
something
to
discuss.
Has
some
comments
and
loads
the
actual
discussions
after
interaction
or
whatever
we
decide,
so
that
can
be
one
way
to
solve
it.
C
B
And
from
from
what
I
saw
from
the
experimentations,
like
with
merge,
request
to
structuring
I'm,
not
sure
if,
if
the
discussions
are
actually
going
to
be
detached
completely
because
we
still
have
changed
the
steps
there,
I'm
not
sure
about
that,
so
yeah
I'll
create
an
issue
about
floating
discussions.
So
we
can
point
to
it.
C
C
C
C
There's
So.
Currently
the
changes.
I
think
this
might
be
related
to
your
changes.
Wait
it's
loading!
Okay,
so
I
think
this
impact
might
be
related
to
the
Chinese
Euro
dog
stands
I'm,
not
sure,
so
we
had
a
some
reduction
on
the
both
the
LCP
and
the
TBT,
although
we
would
like
to
have
more
right.
So
my
question
is
more
or
less
like
what
are
the
ideas
that
we
have
sorry?
This
is
the
wrong
gender.
C
B
I
think
server-side,
rendering
experimentation
is
a
primary
one
because
it
changes
like
it
completely
changes
how
we
render
divs
I
think
this
should
be
it's
the
most
impactful
one
and
the
one
I've
just
presented
with
the
first
point
for
fixed
line
height.
But
as
we
described
it's,
not
it's
not
close
to
being
worked
on
so
right.
Now,
I
only
see
this
gifs
file
SSR
and
past.
C
C
C
B
Think
we'll
we'll
start
with
the
POC,
which
has
limited
functions,
I
think
it
will
have
only
three
divs
and
with
this
will
have
only
discussions
to
see
how
we
can
match
how
we
can
combine
server-side
trading
content
with
interactive
content
and
will
every
every
the
performance
see
if
it
actually
solves
the
problem.
If
it
does,
we
can
proceed
with
the
proper
implementation.
The
good
thing
is
that
we
already
have
a
good
foundation
with
streaming.
C
B
C
But
we
would
probably
need
someone
to
help
you
there,
so
the
question
I
have
with
the
server
side
effort
for
us
to
pick
up
is.
Would
this
effort
include
loading
things
on
the
page,
so
inherently
this
loads
data
onto
the
page?
That
is
not
loaded
by
The
View
app
right.
It's
the
server
side,
giving
us
that
rendered
version,
whether
it's
sync
or
in
a
sync
call
I,
don't
really
care
too
much,
but
are
we
already
prepared?
C
B
I
think
it's
it's
not
that
complex
to
implement.
We
don't
have
like
the
infrastructure
ready
for
it
in
our
front-end
code,
but
it's
trivial
to
implement.
We
do
this
stuff
with
images.
Lazy
loading,
that's
one
approach
to
it.
So
using
a
combination
of
mutation,
Observer
and
intersection
Observer,
that's
one
way
to
do
it,
but
the
other
way
is
to
use
web
components
which
basically
do
the
same
stuff,
but
without
this
manipulations,
so
we
have
a
couple
of
options.
How
to
we
can
do
this
yeah,
but
it
should
be
written
from
scratch.
I
think.
C
B
C
B
B
C
Discuss
the
plan
of
this
early
on
to
the
we're
all
on
board
and
we
can
identify
some,
you
know
roadblocks
early
on
even
before
the
kick
off,
so
we're
going
to
have
a
kickoff
session,
but
before
even
that
we
should
definitely
talk
about
this
planned.
It
feels
like
you
should
also
be
involved,
stands
so
I
want
to
make
sure
that
you
have
time
for
The
View
three
work
migration
and
also
be
involved
in
this.
So
we'll
talk
about
capacity
and
stuff
about
this
I
think
for
1511.
C
A
C
B
C
C
If
you
use
something
else,
something
that
we
could
potentially
guess
on
the
front
end?
What
the
ID
for
each
line
is
so
yeah.
You
started
with
that
conversation
and
it
evolved
into
right.
Well
what
if
we
could
identify
anything
on
the
merge
request,
just
that
lines
happen
to
be
one
of
those
objects.
So
that's
where
the
proposal
comes
from
and
again
looking
at
the
competition,
some
competition
of
code
review
tools
do
allow
you
to
comment
on
different
things.
One
of
the
ones
one
of
the
things
I've
seen
is
some
tools.
C
Allow
you
to
comment
on
the
code
code
on
the
code
structure
say
you
want
to
comment
on
nif
clause
or
you
want
to
call
it
on
the
for
Loop
you'll
be
commenting
on
that
for
Loop
and
if,
essentially,
if
the
file
changes,
the
comment
would
survive.
The
changes,
because
it's
attached
to
the
for
Loop
does
just
an
example
right.
They
go
much
deeper
on
the
analysis
of
that
of
that.
But
what
Thomas's
proposal
you
kind
of
capture
the
discussions
we
had
on
the
call
in
that
issue?
C
Pretty
lengthy,
but
it's
pretty
it's
really
interesting.
If
we
look
at
the
possibilities
that
it
opens
because
we
can
start
re-implementing,
if
we
ever
do
real
permutation
on
a
whole
approach,
we
will
start
with
re-implementing
the
lines
as
being
one
of
the
categories,
but
we
could
extend
that
in
the
future,
for
whatever
we
want
going
deeper
in
the
file
or
line
common,
commit
messages,
all
that
stuff
could
become
later.
If
we
have
it
a
generalized
approach.
C
C
Kind
of
like
reminds
me
some
some
of
that
work,
but
yeah
I
think
that's
more
of
a
long-term
discussion
than
a
short
term.
It's
more
like
is
this
something
we
even
want,
and
if
we
do
whenever
we
pick
up
deep
refactors
of
the
code,
we
should
keep
that
in
mind.
I've
asked
it
last
yesterday
on
the
weekly
call,
so
product
and
ux
take
a
look
essentially
to
kind
of
like
give
us
your
thoughts.
C
B
C
No,
that's
really
that's
a
good
question.
It
would
be
both
I
expect.
I
mean
from
the
moment
that
we
know
where
to
attach
the
comments.
The
front
end
knows
what
to
do
right.
The
common
structure
shouldn't
change,
whether
it's
a
line
or
a
commit
message
or
a
file
name.
It
doesn't
really
need
to
change
the
structure
of
the
of
the
comment.
It
might
change
the
way
that
it
shows
it.
I
know
in
the
past,
I
think
it
was
Peter
that
suggested
that
commit
messages
should
be
displayed
in
the
file
tree.
C
C
Like
we've
talked
about
some
of
those
Concepts
before
so
you'll
be
backing
in
front
end.
Changing
sure
you'll
be
changing
the
way
that
we
attach
things
to
things
that
I'm
being
generic
on
purpose,
but
yeah
we'll
be
back
in
front
and
effort
which
really
only
makes
sense
if
we're
considering
a
refactor
on
the
way
that
we
attach
things
to
lines.
I
think
that's
when
that
this
will
come
relevant.
C
C
So
one
of
the
things
that
is
really
interesting
that
we
had
a
discussion
last
week
was
what,
if
we
used
webassembly
to
Port,
A
C
library,
to
do
syntax,
highlight
syntax
highlighting
on
the
front
end,
but
using
webassembly
instead
yeah
using
a
ruby
gem
on
the
browser
like
so
that's
some
of
the
crazy
ideas
that
we've
been
discussing
there
and
I'm
definitely
willing
to
hear,
because
just
because
it
doesn't
give
us
a
lot
of
support
doesn't
mean
that
there
isn't
something
out
there.
That
does
my
biggest
question.
C
There
is
theoretically
to
do
a
proper
syntax
highlighting
you
need
the
whole
file.
That's
how
you
do
it
on
the
front.
On
the
back
end,
we
got
the
whole
file
we
highlighted,
and
then
we
take
the
Snippets.
We
need
right
to
do
that
on
the
front
end.
If
you
change
two
lines
on
a
10
megabyte
file,
we
will
need
to
download
the
10
megabyte
file
to
the
browser.
That's
to
me,
the
biggest
hurdle
so
yeah
status,
love,
I'm
Keen,
to
hearing
your
thoughts
here.
B
Yeah
I'm
I'm
interested
in
knowing
do
we
really
need
to
move
highlighting
to
front-end,
because
from
our
last
discussions,
I
think
Kerry
mentions
that
it's
actually
like
a
solved
problem
on
the
back-end
side.
So
if
we
can't
keep
it
on
the
back
end
without
performance
issues,
I
think
we
should.
The
best
is
to
keep
it
there,
because
it's
not
changing
any
bites
for
the
front
end
to
to
launch
the
JS
application,
and
also
it
doesn't
have
all
the
issues
with
the
special
highlighting
when
we
start
from
like
from
the
middle
of
the
file.
C
Yeah
I'm
with
Gary
on
this
one,
but
we
opened
the
issue
in
case.
We
we
want
to
like
do
some
investigations
on
it,
I
again
to
me
that
particular
problem
of
the
whole
file.
It's
an
architect,
it's
not
even
an
architecture
of
our
app,
it's
the
architecture
of
our
medium.
That
kind
of
prevents
this
from
happening.
C
Unless
you
start
talking
about
you
know
the
merge
request
using
your
local
file
system
as
the
source
of
the
project.
Unless
you
have
that
I,
don't
think
we'll
ever
be
able
to
do
that
and
again
it's
trying
to
solve
a
problem
that
it's
better
solved
on
the
back
end
anyway
from
the
perspectives.
Yes,
the
payload
is
smaller.
We've
seen
this
in
in
source
code,
the
Emoji
file,
the
Emoji
Json.
It
was
sort
of
like
a
couple
of
couple
kilobytes
in
the
annotated
the
highlighted
version.
Html
was
like
three
megabytes.
B
C
C
Else
that
we
do
on
the
front
end,
which
again,
if
you
look
at
the
competition,
it's
like
download
the
static
download,
the
things
that
are
static,
ready
to
be
put
on
the
page,
and
then
we
deal
with
interaction
when
the
user
interacted
interacts
with
it
and
that's
a
far
more
interesting
approach,
then
doing
more
and
more
and
more
things
on
the
front
and
then
we're
trying
to
keep
performance
so
I
don't
know
I
just
rate
it,
because
it's
open
but
I'm
with
Kerry
I.
Think
it's
a
solid
problem.
C
C
C
C
Of
things
in
here,
which
is
one
thing,
is
the
metadata
in
the
descriptions
and
all
that
stuff
that
we
need
to
write
anymore.
It
could
be
created
upon
an
edit
or
a
product
creation
or
an
edit
on
the
merge
request
and
then
the
file
changes.
We
really
only
need
well,
we
need
to
generate
those
every
time.
There's
a
push.
However,
if
we're
comparing
with
the
with
the
with
the
head
of
the
of
the
target
branch,
we
need
to
update
that
cache
every
time.
C
The
target
moves,
which
would
make
a
lot
of
work
happened
a
lot
of
the
time
in
our
case
of
our
emergency
of
our
repository
right
and
so
our
fast-moving
repositories.
It's
really
hard
to
keep
that
cache
updated
right,
because
it's
the
diff
it's
constantly
changing.
That
could
be
a
hurdle,
but
anyway,
that's
the
issue.
A
A
C
Yeah
definitely
worth
for
some
projects,
so
other
projects
will
probably
not
be
as
easy
to
handle.
What
I'm
thinking
is
every
time
the
master,
Branch
or
a
main
branch
of
a
project
moves
gets
new
commits.
If
we
had
to
go
to
Every
Mr
targeting
that
branch
and
update
it,
that's
quite
a
workload
to
do
so.
There's
definitely
something
in
there
that
we
need
to
consider,
but
yeah.
B
C
Right
we're
out
of
time
people.
Thank
you
so
much
for
the
discussions.
I,
don't
know,
I,
don't
know
who
started
the
live
stream,
but
I
think
I'll
be
able
to
catch
it
anyway
and
change
the
visibility
of
it.
So
I'll
publish
it
thanks
for
streaming
it
and
starting
it,
and
thanks
for
a
wonderful
discussion,
great
to
see
you
Patrick
yeah.
Thank
you
hope.
You're
well,.