fun fun function so today I want us to
think about performance the very
clickbait the title of this video is
fast code is not important what is
important is fast user experience there
is a relationship between the two but
it’s not as strong as you would think
even though we as programmers would
really like it to be on an emotional
level it would be like it seems to me
like if I just write performant code all
the way through and follow all the rules
then my app will be fast right that
seems like the way it should be but as
we often learn in life the universe is a
weird and unpredictable place and things
are not so at all as we think that they
should be before I get into this video I
want to make crystal clear so that
nobody misunderstands me here that I
think that performance software
performance is extremely important but I
do think that a lot of developers have a
much too simplistic and a narrow view of
what performance is and that is what
this video is going to be about I
believe that one of the main aspects
that sets an adult aside from a child is
that the adult is aware that he or she
is inside a context both the adult and
the child has a a conceptual model of
the world set of understandings or
beliefs or sets of principles but the
thing that sets the adult and child
apart is that the adult is aware of
their context the people around them the
limitations of the current situation for
instance a child learns early on that
you should be nice to others that’s a
good heuristic of dealing with other
humans you should be nice to them but
it’s not quite a universal truth because
there are people that are not nice and
will not respond well to nice and
sometimes you
we’ll have to be not nice to them so
perhaps you expand the rule to being be
nice to people as long as they’re nice
to you but over time you learn as a
child that there might be exceptions
even to that rule because sometimes nice
people are being manipulative or perhaps
the nice people just simply want
something else and you do on your
interest or in conflict and and it might
not be possible to be nice the world is
a really complex place and we have these
simplified models in our heads that help
us to reason about the world if real
life doesn’t go according to the mental
model that will cause a lot of
disappointment in you and a child who is
not used to their school threw a tantrum
a mature person that one that we
consider an adult and a leader they are
also disappointed because they also have
a mental model but they know that the
mental model is just a model and doesn’t
really correspond to the to the actual
world and they know how to adapt when
their mental model breaks down when I
say child and adult I I’m speaking in a
more general sense and just growing up
and becoming larger and more of age I’m
talking about learning things in general
for instance I dance the Lindy Hop
sometimes it’s a couple’s dance and when
you first learn that they teach you a
very simplified set of rules of how to
how to dance it’s not really the dance
it’s just a very simplified form of the
dance but the simplified model allows
you to reason about the dance and and
and have it not overwhelm you at that
phase but as you grow you learn that
these rules are a lot more flexible than
you were initially led to believe and
that’s okay in the beginning we had
simple rules so that you would not be
overwhelmed but as you grow you need to
be able to become more flexible and
understand
and things holistically I made a video a
while back on factory functions which is
an alternative simpler version to create
objects in JavaScript rather than using
the prototype or classes and the most
common response to that video is people
asking aren’t the prototype doesn’t the
prototype have better performance
characteristics and memory
characteristics than factory functions
and the answer to that is yes but only
if you view it in this little
constrained simplified situation in a
real life application things like that
or just not gonna matter there is a site
that you have probably seen it’s called
J’s perf comm where you can write little
JavaScript snippets and put them
side-by-side and have them execute
millions and millions of times next to
each other and then you see like which
one was the fastest so people write
these micro benchmarks next to each
other find out the the one that is
fastest and then they do blog posts and
they post saying that this is the way
you should for Strings or this is the
way you should create objects because
this is the fastest and this is all very
alluring to me as a human because it
gives me this unambiguous way of doing
things the optimal way but there are two
problems with looking at operation
performance like this you know that the
time it takes to perform this single
type of operation optimizing that the
first problem is that javascript
compilers are pretty smart for me there
are many cases where I’ve written
insanely inefficient code and just with
the excuse that I yeah I just can try
this and then optimize it later because
that really needs to be optimized and
only to realize that the code runs
insanely fast for no obvious reasons but
probably because it was being optimized
by the v8 compiler into something really
really performant automatically and also
there is a lot of competition going on
among compilers especially in the job
script community so uh one thing that is
slow today might not be slow next week
it’s so hard to look at a given piece of
code and tell if that is going to be
inefficient or not because they’re so
much more going on underneath you when
it comes to single operation performance
you just have to accept that you don’t
really know if something is gonna be
fast or not because even if you’ve read
some blog post saying that this is slow
that might have changed since then or
the particulars of your applications
will make it easy to before the Optima
compiler to optimize but the second
problem is much bigger and that is that
focusing on a single operation gives us
this kind of tunnel vision which makes
us forget the more cohesive whole
thinking about the factory functions
versus prototypes example factory
functions are about 30% slower than
prototypes and you might think that wow
that’s a lot until you consider the fact
that they are both insanely fast whoa
okay
so my phone can create 643 million
JavaScript objects per second we live in
the future but those are simple objects
perhaps they are more complicated and
you have more memory considerations and
perhaps you genuinely do need to create
millions of objects per second you’re
doing some 3d thing in JavaScript or
something
I don’t know let’s just say do if you’re
in that situation it might be wise to
look into how you can create every orbit
more effectively but it’s more likely
that it’s better for you to think about
can I avoid creating this many objects
in the first place and this leads us
into algorithmic performance algorithm
is a fancy word in programming – it’s
almost synonymous with approach let’s
say that you have a list and you need to
find an item in that list a naive
algorithm
would be just going through the list all
the way until you find the item and then
you return it you might make that
algorithm more efficient by you could
for instance sort the list keep it
sorted and that way you can be clever
about where you start searching in the
list because we know that an item can’t
be in some areas for instance or if
you’re creating many millions of objects
per second you might be able to cut that
number of items down if you only draw
the objects that are on screen at a
given time for instance this is often
referred to as time complexity or just
efficiency in algorithms you’re not so
concerned with how much memory or how
much performance each individual step
takes you are more interested in making
sure that those steps doesn’t happen in
the first place
algorithmic performance is a lot more
sensible way of thinking about
performance rather than looking at micro
benchmarks on J’s perf
but it still suffers from the same
problem in that it it has this
simplified alluring view of the world it
gives us the ability to break a problem
down into this simplified model that we
can just reason about and we can make it
better and we can feel good about it and
I can really relate to that algorithms
are fun they are and that is also what
makes them a bit dangerous because in
most cases an algorithm doesn’t live on
its own unless you’re an academic
developing yet for a paper it will live
inside a bigger system a big system that
it’s probably gonna be millions of lines
of code and because you know humans grow
old on our time on this earth is limited
you’re just not gonna have the time to
write all the code in the perfectly
optimal way so you need to know how to
direct your efforts so when you optimize
you need to know what parts of the code
are hot and what I mean by that is what
parts of the the execute
what execution paths are taken by the
user a lot if you spend a lot of your
time optimizing some loading code and
that loading code is only used in the
settings dialog which the user will only
go into once or twice a year that will
be a very bad investment of your time it
might actually be a better use of your
time optimizing saving 50 milliseconds
of the time it takes to open the menu
for instance because that might be
something that user uses a lot in the
end the only sensible criteria to use
for the performance of an application is
to ask the user does this feel fast and
once you identify parts of the
application where it doesn’t feel fast
for the user you yes you can put your
tunnel-vision there instead and locate
like okay this this this view here this
is not loading quite a snap yes it
should be why and then you hit the
profiler I am a firm believer that fast
applications are born in the profiler
nowhere else it’s almost impossible to
write code upfront that is it’s going to
be make the application fast instead you
have to look at the cookies the cohesive
product and figure out which parts of
are slow and eliminate them one by one
so in summary I would like you to keep
at the back of your mind that fast code
does not equal fast software think about
the performance of your app holistically
and don’t get caught up in pieces of
code leave you with links to three
excellent videos that I would like you
to watch the first one is a taught by M
R olive who is this amazing Russian
compiler engineer that it’s a hilarious
talk you really need to watch it the
second talk is a talk by Paul Lewis from
Google who is an amazingly funny guy and
really really good speaker and he talks
about something that he calls rail which
is has nothing
do with Ruby on Rails its instead of a
way of thinking about performance
what is slow what does that mean and the
third one is a more meaty video where
they show how to do raelynne in practice
using the chrome developer tools and
don’t skimp on this even if you’re not a
web developer because these principles
are really good in general I am mpj and
this was an episode of fun fun function
and I make these episodes every Monday
morning so you should subscribe so that
you don’t miss the next one if you’ve
already done that and you don’t want to
wait for the next one you can click here
to see if one of the other episodes
tickles your fancy until next Monday morning stay curious