►
From YouTube: 2020 07 03 GSoC Git Plugin Performance Project
Description
Jenkins git plugin performance improvement project in Google Summer of Code.
A
Okay,
so
just
one
second
yeah,
so
the
first
agenda.
For
today,
the
demo
we
had
the
first
thing
I
wanted
to
tell
you
that
I
have
raised
the
P
hat
for
the
blog
post
and
I,
like
you
guys
to
review
it
and
as
soon
as
we
can
publish
it.
So,
apart
from
that
from
the
demo,
what
I'd
like
to
discuss
is
O'lakes
comments.
He
he
was
talking
about
about
the
scope
of
our
benchmarking
strategy
and
he
was
he
was.
A
He
gave
a
suggestion
that
we
should
also
consider
he
depends
as
far
as
I
could
understand
him.
He,
the
dependencies
upon
which
the
gate
plug-in
works
like
the
credentials
API.
We
should
also
consider
them
by
we're
benchmarking
in
the
plug-in
so
I'd
like
to
discuss
that,
because
I
think
this
meeting
we
can
use
it
to
plan
what
we
want
to
do
for
the
next
phase
and
yeah.
So,
first,
let's
just
discuss
what
Oleg
was
saying:
Matt
I
am
actually
not
I
haven't
explored
the
dependencies
of
gate
plug-in,
so
this
much
I
could
understand.
B
I
think
I
think
so
audio
check.
First,
can
you
hear
me?
Okay,
I'm,
not
sure,
let's
well-behaved,
okay,
great,
so
the
I
believe
his
concept
was
that
there's
a
higher
level
or
no
there's
already
in
Jenkins
a
layer
at
which
things
operate,
for
instance
in
a
job,
and
you
see
them
when
you
run
a
job,
the
output
is
there
where
it
does
a
git
version
command,
and
then
it
does
a
git
config
something
and
it
does
something
else
and
and
I
think
what
he
was
expressing
is.
Could
that?
B
Could
we
benchmark
the
aggregate
of
all
those
things
together
and
get
useful
information
with
the
intent
of
looking
for
things?
We
could
stop
doing
or
do
differently,
as
as
an
example
in
the
in
the
checkout
process.
When
you
watch
the
the
commands
that
are
being
being
reported,
one
of
them
is
it's
doing
a
git
config,
so
it's
actually
calling
command
line
GUID
and
doing
a
git
config.
That
is
an
obvious
target
for
a
jacott
transition
so
that
we
don't
have
to
fork
a
process.
B
B
A
I
think,
as
far
as
I've
learned
about
I've
research,
about
micro,
benchmarking,
the
general
advices
to
micro,
benchmarking,
exactly
means
to
I
to
isolate
to
a
single
point
in
your
operation
and
then
try
to
test
it,
because
if
we
are
trying
to
bench
once
the
whole
operation,
the
amount
of
variables
will
have
be
unknown
variables.
It's
that's
something
which,
for
that
I
considered.
That
is
well
to
to
time
the
whole
process
as
well,
because
I
discuss
it.
A
One
of
the
meetings
about
the
scope
of
the
benchmark,
a
big
benchmarking
strategy
that
maybe
we
could
also
write
something
right,
some
kind
of
benchmarks
for
the
plug-in
Gate
plug-in
as
well,
because
that
information
might
be
more
useful
for
the
user,
with
the
benchmark
setting
in
the
gate,
client
plug-in
who
benchmarking
the
same
operation,
then
there
might
not
be
too
much
change
in
the
operation,
leave
a
gate,
fetches
working,
so
benchmarking
the
same.
The
benchmarks
just
serve
the
purpose
for
once
that
we
benchmark
them
and
we
gain
insights.
And
then
we
use
those
results.
A
But
if
we
have
some
benchmarks
at
the
level
of
the
gate
plug
in
operations
which
would
involve
like
the
same
chapter,
it
involves
a
combination
of
gate
operations.
So,
if
you're
able
to
benchmark
that
at
each
build,
any
developer
creates
adamah
with
the
master
branch.
That
would
be
very
useful
for
that
person.
If
they're
changing
anything
and
the
performance
is
increasing
or
decreasing,
or
if
it's
being
affected
by
that.
But
then
what
at
that
meeting
or
what
you
the
Mentors,
we
decided
that
that
would
be
for
the
current
scope.
It
would
be.
A
It
could
be
something
we
could
do
once
we
achieve
what
we
want
to
right
now,
but
right
now
that
would
that
that
isn't
something
we're
looking
for.
So
so,
if
it's
something
we
want
to
consider,
maybe
we
can
right
now
I
think
the
current
issues
we
have
its
first
for
an
example.
First
I
need
to
the
benchmarks:
I
do
for
the
for
a
single
operation.
A
I
need
I
need
to
be
more
confident
that
I
am
able
to
get
good
results
and
we
are
able
to
actually
use
those
results
in
the
plug-in
once
we
maybe
we
exhaust
those
avenues
of
exploring
single
operations,
and
we
are
not
able
to
find
any
useful
insight
to
improve
the
performance.
Maybe
we
can
move
up.
Would
that
be
a
good
strategy
that.
B
That
suits
me
just
fine
I'm,
still
I
I,
think
I.
Think
you
got
at
Oleg's
what
I
took
from
Oleg's
suggestion
was.
If
we
had
completed
the
other
objectives
that
we
had
said,
we
could
go
to
a
higher
level.
I,
don't
think
that
we've
completed
those
other
objectives
yet
and
I
think
there's
much
to
be
learned
still
in
the
in
the
and
at
the
level
that
had
been
defined
so
not
not
discount
I,
it's
very
dangerous
for
me
to
ever
discount
that
genius
that
I
work
with
he
is
he
is
a
delight.
B
A
Okay,
okay,
that
sounds
good
okay,
so
the
second
King
is
the
bottom.
The
demo
are
we,
so
we,
the
PR
for
the
fix
for
the
redundant
right
issue,
was
merged,
but
it
was
also
marked
requested
and
obtained
opt
out
global
switch,
which
would
be
helpful
for
some
of
the
users
if,
if
our
logic
is
not
correct,
so
so
with
that
before
discussing
the
issue,
I
I
would
also
like
to
ask:
should
we
should
we
add
any
issue
track?
Should
we
start
tracking
our
issues
with
JIRA?
A
Why
I
say
this
is
because,
when
we
were
discussing
this
issue,
I
I
thought
by
mistake
that
when
we
are
talking
about
the
global
switch,
we
are
talking
about
the
switch
which
we
will
implement
in
the
performance
improvements
once
we
have,
the
performance
improvement
so
I
was
I
was
actually
not
aware
that,
at
the
time
when
you
asked
by
merging
after
the
merging
DPR
that
we
need
an
opt-out
switch
for
this
fix
as
well,
I
was
not
aware.
I
forgot
and
I
did
not
track
it.
A
So
I
was
thinking
and
also
also
one
more
thing
with
this
issue.
Is
that
sometimes
we
discuss
what
we're
going
to
do?
I
raise
a
PR,
but
it's
maybe
not.
Everyone
is
involved
with
the
PR
so
for
for
everyone
here
to
follow
what
is
happening
with
the
issue
and
the
subtasks,
and
if
we
have
people
can
go
and
update
it.
B
Yeah
if-if-if
jeera
yeah,
I
love
that
you've
suggested
using
jira,
that's
great
and
and
if
you
think
it
will
help
you
in
any
way
you
have
my
wholehearted
support.
That's
I
I
flinch
because
get
plug-in
is
the
number
three
highest
owner
of
giddy
shove,
open
issues
in
JIRA.
It's
second
only
to
Jenkins
core
and
the
maven
plug-in
no
and
blue
ocean.
B
A
So
I
and
with
the
so
with
the
issue
with
the
opt-out,
switch
I
was
talking
about
so
I
implemented.
It
in
iris
appear
for
it
Marcus
unit,
but
with
the
implementation.
There
is
a
one
problem
and
the
problem
is
that
it's
not
persisting
for
each
build
for
one
build.
I
configure
it
and
I
and
I
and
I
start
the
build
it
works.
The
switch
is
working
as
it
should,
but
once
the
build
is
complete,
I
again
go
back
to
jenkins
configure
page
it's.
A
B
You'll
see
a
very
simple
difference
in
terms
of
the
api
naming
convention
and
that
api
naming
convention
is
all
all
the
crucial
thing
here,
because
it
breaks
the
coupling
between
the
user
interface
and
the
getters
and
setters
and,
and
it
tragically
gets
absolutely
silent
that
the
connection
is
broken
it
just
it
doesn't
show
you.
Oh
I
I
tried
to
set
something
in
Java
ignored
me
completely.
Oh
that's.
B
A
I
think
the
mistake
is
that
I
was
confused
with
using
redundant
fetch
or
the
second
fetch,
because
if
we
are
giving
an
option
to
the
users,
I
feel
that
this
we
should
not
call
it
a
redundant
fetch
because
we
it
it
is
not
redundant
for
them.
So
it
should
be
called
second
page,
but
we
were
using
the
dungeon
fetch
for
a
long
time,
so
I
I
think
I
I,
redundant
fetches.
So
there's
a
confusion
there
in
the
codes.
I'll
change
it.
Okay,
yeah.
B
Well,
and
and
and
but
your
your
attention
to
hey,
we,
we
don't
rename
things
just
casually
is
actually
quite
important.
We
haven't
yet
released
the
the
redundant
fetch
removal,
so
we
can
still
freely
rename
things
once
we've
released,
something
a
public
symbol
in
Jenkins
becomes
tragically
and
unforgivably
part
of
the
public
API.
Even
if
you
didn't
want
it
to
be
so
you're
naming
mistakes,
my
naming
sins
from
four
years
ago
are
still
very
much
in
the
in
the
code
and
they
have
to
be
otherwise
we
break
compatibility.
B
A
Going
to
do
that
now,
okay,
so
after
that,
I
was
thinking
to
plan
what
we
want
to
do
for
phase
two
and
and
also
with
the
planning
I
think
what
I
wanted
to
discuss
was
what
we
did
is
I
ate
in
the
phase
one,
what
we
did
wrong
according
to
you
guys
and
what
we'd
like
to
continue
and
what
we'd
like
to
draw
so
something
in
that
format.
So,
let's
start
with
what
we
I
think
I'm,
not
sure
what
we
like.
B
Yeah
come
on
so
I
was
delighted
with
your
progress
and
with
your
engagement,
really
thrilled
and
excited
to
watch
the
progress
excited
to
see
the
engagement
very
positive
of
loved
it
and
that
it
was
done
by
code
requests,
pull
request
by
looking
at
code
and
by
that
and
that
you
were
willing
to
do
interactive
testing
at
the
places
where
interactive
testing
actually
was
more
effective.
I
like
that,
it's
it's
uncommon
for
a
student
to
realize
that
interactive
testing
is
actually
sometimes
the
most
valuable
thing
you
can
do
at
certain
points
in
a
project.
A
That's
an
important
thing.
I
one
of
the
important
things
I
learned
that
just
writing
a
fix
is
not
important.
Compatibility
is
a
very
essential.
I
would
say
thing
to
remember,
while
you're
writing
anything
for
four
for
a
tip
for
a
plug-in
or
for
a
utility
which
is
being
used
by
so
many
users.
Well,
it's.
B
A
good
it's
a
fair
point
that
in
different
environments,
the
compatibility
requirements
are
different
right.
If,
if
you
join
an
employer,
that's
writing.
Linux
kernel
work.
They
care
much
much
more
about
compatibility
than
we
even
dream
of.
If
you're
doing
brand-new
blue
sky
code
compatibility
is
not
relevant,
go
as
fast
as
you
can
yeah.
D
D
If
you
know
that
idiom,
so
it's
good
to
see
that
you
know
you
take
take
stuff
on
you.
Do
some
research
on
unstuff
present
some
options,
which
is
nice,
it's
good
for
us
to
hear
I.
Think
in
any
like
software
development
project,
it's
good
for
if
you're
working
on
a
task
you're
showing
other
people
on
your
team,
the
options,
it's
always
helpful
because
they
may
come
up
with
other
things,
but
they
may
also
have
a
head
start
in
thinking
about
the
different
options
because
you've
you've,
given
some
of
those.
C
C
So,
tilde
time,
like
last
four
weeks,
those
have
been
amazing.
Like
your
work,
it's
pretty
pretty
like
more
than
pretty
grid
and
the
yesterday's
presentation
was
amazing
and
the
best
part
of
you
that
I
felt
was
like.
You
are
able
to
go
with
the
approach
and
if
you
find
anything
wrong,
you
are
like
open
enough
to
expose
that
Fault
in
the
approach.
That's
the
best
thing
that
I've
found
till
Oh,
yep
and.
D
C
A
A
B
So
one
of
my
worries
was
that
if
we
were
as
mentors
redirecting
you
a
little
too
comfortably
that
we
were
hey,
let's
just
go
off
plan
a
little
bit
a
little
bit,
because
we
think
this
other
idea
looks
interesting
and
attractive
and
and
I
wonder
if
as
mentors,
this
is
not
not
your
fault,
this
is
really
a
mentor.
I
swear,
sometimes
I.
It's
very
easy
for
me
to
get
interested
in
the
most
recent
shiny
thing
and
and
go
after
the
interesting
recent
shiny
thing.
B
D
Yeah
I
would
agree
like
I,
think
I've,
probably
given
some
suggestions
that
may
have
like
taken
you
but
I,
don't
think
you
I
think
you
justifiably
we're
like
took
these
suggestion,
and
maybe
you
I
think
we
stayed
on
schedule.
So
I
think
we
were
good,
I
guess
I,
don't
I
went
too
far.
Yeah
I
think
the
only
thing
I
can
think
of
is
probably
also
scheduled,
related
and
and
I'm,
not
sure
that
this
is
necessarily
something
on
you,
but
I
guess
we
have.
D
C
Sirisha
I
generally
keep
on
following
that
particular
thing
like
I,
followed
the
agendas
for
meeting
and
I
also
check
on
the
proposal,
so
I
think
we
are
definitely
on
the
track,
but
I'm
not
sure
of
the
timeline
at
what
what
I
meant
exactly.
We
need
what
milestone
we
need
to
achieve
the
third
time
exactly,
but
we
are
definitely
on
the
track.
Correct.
D
C
D
It's
a
software
project
to
you
so
I
mean
software
projects.
You're
not
gonna,
be
a
hundred
percent
accurate
with
what
you
thought
a
month
ago,
or
maybe
even
a
week
ago,
sometimes
with
how
long
it
actually
takes.
So
that's
just
a
reality.
So
sometimes
you
just
need
to
readjust.
So
that's
kind
of
where
that
cadence
of
maybe
are
we
in
the
right
spot
or
do
we
need
to
readjust?
A
A
B
The
idea
of
looking
at
the
timeline
I
tend
to
ignore
timelines,
so
we
may
want
to
make
a
systematic
thing
in
these.
Maybe
one
one
of
the
sessions
in
a
week
where
we
remind
ourselves
the
timeline
was
this:
are
we
okay
with
deviating
from
the
timeline
or
not,
because
I've
I've
been
totally
oblivious
to
timeline
thinking
instead
about
tasks
and
photo?
A
So,
according
to
me,
what
my
expectation
for
Faceman
was
that
I
would
the
fix
the
redundant
fix,
because
that
was
something
for
that
I
attempted
the
fix
even
before
the
g-shock,
the
community
bonding
phase
started.
So
I
was
so
what
I
thought
was
that
I
would
write
the
benchmarks
I
had
one
benchmark,
I
would
write
more
benchmarks
and
I
would
possibly
try
to
discover
more
issues.
A
Related
issues
and
side
by
side.
Try
to
find
a
solution
on
how
to
implement
those
in
the
player
again,
but
I.
Think
where
I've
lagged
is
that
I've
spent
too
much
time
on
on
benchmarks
and
I
think
my
my
goal
was
to
find
the
difference,
even
if
they,
my
goal
was
to
find
a
difference
and
I'm,
not
sure.
If
that's
how
much
that's
helpful,
maybe
it's
helpful
to
a
point.
But
if
you
overdo
it,
then
you
maybe
you'll.
You
know
I'll
try
to
see
results
where
I
there
did
not
they're,
not
existent.
A
So
that's
one
one
concern
I
have
with
myself
and
I.
Think
I'm
going
to
change
that
when
I'm
doing
the
benchmarking
thing
and
also
I
think
I
need
to
maybe
I
need
to
put
a
stop
at
where
I
I
go
with,
with
the
results.
I
have
and
parallely
try
to
focus
on.
The
fact
that
we
need
what's
more
important.
Is
that
the
existing
results
we
have?
A
We,
we
have
a
system
to
add
them
inside
the
plugin,
and
that's
going
to
be
that's
going
to
take
a
lot
of
time,
because
when
I
was
planning,
the
timeline
I
was
not
a
made
aware
of
how
much
time
it
would
take.
I
thought
that
it's
going
to
a
coding,
a
certain
task,
would
not
take
too
much
time.
I
was
not
aware
how
much
time
after
the
coding
process
would
take.
That
is
the
testing
of
it
and
then
the
taking
it
to
production
that
whole
process.
I
I
was
not
aware
whether
while
I
was
writing.
A
And
with
the
git
fetch
issue,
what
I've
seen
is
that
it?
It
would
take
considerable
time
in
this
case
in
for
this
plugin,
for
this
repository,
so
so
so
I
think
there
has
to
be
a
fine
balance
between
how
much
I
research,
because
I
think
I
feel
that
this
project
is
not
50%,
but
it's
somewhere
around
the
research
we're
doing
exploring
and
50%
it's
using
that
to
code
things.
So
so
it's
really
important
that
I
balance,
both
of
them
I,
think
I
could
not
balance
this
time.
A
For
this
phase,
coding
was
less
and
research
or
finger
figuring
out
ways
to
consolidate
the
results.
I
have
profiling
and
then
looking
into
how
the
operation
is
working.
Also,
so
I
do
explore
the
code.
I
do
try
to
understand
as
much
cool
code
as
I.
Can
it's
not
like
I'm,
not
reading
code,
but
I
I
believe
that
I
did
not
I
should
have
find
found.
A
What
clear
observations
we
have
is
with
the
benchmark
results
of
gate
sketch
is
that
J
gave
the
size
of
positive
the
J
gate
thing
we
have
and
with
a
less
remove
it's
it's,
it's
not
much
of
a
difference,
but
I
think
that
I
I've
spent
much
more
time
to
find
more
things.
So,
if
that's
a
good
thing,
I
think
to
a
limit,
it's
good,
but
not
at
the
cost
of
not
providing
a
solution
which
is
actually
what
we
want.
A
Ultimately
for
this
project,
so
I
think
that's
one
of
the
biggest
concerns
I
have
and
I
would
so
with
tracking.
What
I
want
to
do
is
that
I
think
that
would
help
me
more
to
stay
within
the
line
and
code
as
much
as
I
really
searched
for
the
benchmarks.
So,
yes,
that's
I!
That's
what
I
feel
for
the
face
bunch
yeah.
D
I
mean
I
think
some
of
the
beginning,
and
this
is
like
some.
What
you
said
is
the
nature
of
your
teeing
everything
up
your
bootstrapping
all
the
stuff
to
gain
and
damages
later
to
you
saw
it
yeah.
That's
probably
a
lot
of
nature
of
the
beast
kind
of
thing
and
yeah.
You
don't
know
what
you
don't
know.
So,
yes,.
B
B
So
yeah
I
like
that,
a
lot
balancing
that
which
probably
has
very
specific,
concrete
things
with
exploration
of
are
there
any
other
operations
besides
fetch
where
J
get
is
substantially
slower
or
substantially
faster
than
CL
I
get
because
right
now,
we've
we've
you've
benchmark
two
or
three,
and
one
of
the
benchmarks
says
yes,
clear
difference
the
other
one
says:
no,
not
a
clear
difference.
The
question
is
that
all
right,
which
or
should
we
continue
writing
more
benchmarks?
Or
rather
is
it
put
you
focus
fully
on?
B
A
I'd
like
to
do
both,
because
if
we
don't
explore,
then
then
I'm
not
sure
how
much
we
like
we
would
be
good.
We
could
cover
at
the
end
of
the
project,
so
I
would
not
like
to
stop
the
researching
into
the
different
areas
of
this
plugin,
but
but
then
again
focus
on
the
coding
task.
This
much
so
the
last
question
I
have
is
so
now
I'm
going
to
write,
ideally
either
I'm
going
to
add
the
size.
Estimated
part
of
the
code
to
the
gate,
SEM,
telescope
or
I
could
create
a
new
class.
A
That's
I
I'll
work
on
that
more
first
I
have
to
give
more
time
to
that
thought,
but
I
wanted
to
ask
since
I
would
have
to
design
a
class
and
what
would
be
good
design
principles.
I
should
maybe
read
about,
or
if
you
guys
could
give
me
some
advice
on
how
I
should
design
such
a
class,
where
I'm
I
have
heuristics
and
I
want
to
I'm,
not
very
sure
of
the
thing.
I'm
delivering,
but
I
have
some
kind
of
an
estimate.
A
So
this
is
a
very
new
type
of
I
would
say
a
functionality
for
me
to
get
so
I
just
like.
If
there's
some
possible
advice
or
maybe
things
you
would
like
me
to
explore
before
I
write
this
class,
because
I
think
if
I
have
some,
if
I
read
some
good
principle
and
then
I
try
to
code
them
really
easier
for
us
to
then
review
it
and
the
process
will
be
fast.
I
think
that's
the
right
way
to
do
it
so
yeah.
B
A
B
Get
SCM
telescope
for
me
feels
like
a
great
pattern
and
a
great
place
for
you
to
explore.
It
I
think
that
is
exactly
the
concept
and
if
you,
if
you
read
the
SCM
API
documentation
as
written
by
Stephen,
he
has
a
page
called
consumers
for
consumers
of
the
SEM
API.
You
can
read
more
about
his
strategy
and
why
he
did
get
SEM
telescope.
B
What
his
concept
was
so
so
that
consumer
documentation
on
SCM
api
is
a
really
really
good,
read
and
therefore
you're
reading
from
some
of
you
actually
is
a
good
designer,
as
opposed
to
listening
to
me,
who
is,
we
know
not
a
good
designer
right,
I'm,
I'm,
pretty
solid
of
maintenance
programming
and
pretty
solid
at
testing
I'm,
not
really
great,
at
designing
new
code.
So.
D
D
Good
gem,
like
I,
think
what
you
hit
on
is
is
kind
of
what
I
was
gonna,
say
too
I
think
different
code
bases
kind
of
sometimes
tend
towards
different
practices
and
stuff
like
that
too.
Javis
generally
has
good
practices
and
there's
like
books.
You
can
read
on
on
this
and
stuff
like
that,
but
I
think
I'd
agree
with
Marc
that
take
a
look
at
what
you
have
for
this.
D
Take
a
look
at
other
classes
that
have
been
designed
in
here
that
might
do
something
somewhat
similar
and
you'll
be
able
to
potentially
snip
some
of
those
things
from
there,
but
also
combine
that
with
iteration,
because
you're,
not
gonna,
I,
don't
know,
I
think
as
many
times
that
try
to
design
classes
like
I
usually
find
something
or
another
thing
when
I'm
testing
it
or
writing
unit
tests,
or
something
like
that.
That
I
might
change
some
stuff
up
anyway.
So.
A
Okay,
yeah,
that
sounds
that
sounds
okay,
I
lied,
it's
started
of
exploring
the
get
a
simple
asthma
be
focusing
on
it.
First,
yes,
iam
telescope
and
reading
the
consumer.
Okay,
then
maybe
come
up
with
the
prototype,
and
then
we
can
discuss
the
design.
Maybe
it's
not
the
right
time
to
ask
the
question
so
yeah.
A
But
I
think
it's
it's
good
that
we
already
have
a
class
which
is
doing
similar
its
design
for
the
similar
purpose,
so
I
think
I
should
look
at
that
first
and
then
yeah
okay,
so
so,
okay,
just
one
mistake
before
and
in
the
meeting
I
I
was
always
planning
to
document
the
process
we've
gone
through
for
the
benchmarking
I.
Never
did
it.
C
A
I
would
say
benchmarking
with
benchmarking,
as
I've
already
mentioned
in
the
presentation,
we
would
widen
the
scope
I.
The
start,
okay,
I
haven't
discussed
with
the
benchmarking
I
think
we
can
discuss
it
in
the
next
meeting
as
well
with
the
benchmarking
I
want
to
focus
on
the
repository
structure.
That
is
the
commit
history,
number
of
branches
and
other
parameters
in
the
size,
keeping
the
size
constant.
If
that's
possible,
then
the
second
thing
would
be
different
platforms.
A
I
haven't
focused
enough
on
how
different
the
operations
are
working
on
Windows
versus
Linux
I
would
like
to
focus
on
that
and
then
once
I
have
observations
from
that
experiment.
I
would
move
on
to
the
suggestion
given
and
by
mark
to
run
it
on
different
platforms
on
the
infrastructure.
You
can
give
this
what
I
Oh
so
yes,
yes,
ma'am,
aren't.
B
We
going
to
get
that
we're
already
running
the
jmh
benchmarks
that
you've
created
on
different
platforms
on
CI
that
Jenkins
that
I
own.
Now
we
can't
see
the
results
nearly
as
conveniently
as
what
you've,
what
you've,
what
you've
shown
in
your
environment.
We
don't
have
the
jmh
plugin,
we
don't
have
that
benefit,
but
but
they
are
running
and
so
so
I
yeah,
I,
think
I.
Think
it's
yes.
C
A
Promise
I
would
have
to
make
is
just
to
analyze
them.
I
did
not
take
pools
of
side
by
side
and
analyze
them.
That's
something
I
mean
yes,
so
I
would
but
mark
with
that.
Okay,
I'll,
discuss,
indicated
channel
I
think
the
time
is
over
it's
a
small
thing
and
discuss
it
integrated.
Thank
you
guys.
Thank
you.
So
much
all
right.
Thanks
everybody.