Fast code is NOT important - FunFunFunction #27

good Monday morning I am mpj and this is fun fun function so today I want us to think about performance the very clickbaity 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 performance 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 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 and 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 um 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 uh 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 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 uh and sometimes you will have to be not nice to them so perhaps you expand the rule to being uh be nice to 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 uh nice people just simply want something else than you do and your interests are 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 uh go according to the mental model that will cause a lot of disappointment in you and a child who is is not used to this will throw a tantrum a mature person that one that we consider an adult and a leader uh 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 than just growing up and becoming larger and more of of age I'm talking about uh learning things in general for instance I dance the Lindy Hop sometimes uh it's a couple's dance and when you first learn that they teach you a uh 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 uh 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 things holistically I made a video a while back back uh on uh Factory functions which is an alternative simpler version to create objects in JavaScript rather than uh using the Prototype or classes and the most common response to that video is people asking uh aren't uh 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 uh simplified situation in a real life application things like that are just not going to matter there is a site that you have probably seen it's called JS per.cup 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 fastest and then they do blog posts and they post saying that this is the way you should parse strings or this is the way you should uh create objects because this is the fastest and this is all very alluring to me as a human because it gives me uh this unambiguous way of doing things the optimal way but there are two problems with looking at operation performance like this you know the the time it takes to perform this single type of operation and optimizing that the first problem is that uh JavaScript compilers are pretty smart for me there are many cases where I've written insanely inefficient code and just with the excuse that yeah I'll just going to 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 JavaScript 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 there are 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 going to be fast or not because even if you've read some blog post saying that this is slow uh that might have changed since then or the uh particulars of your applications will make it uh easy for the optim 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 uh which makes us forget uh the more cohesive hole 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 6403 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 uh 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 object 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 to um 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 uh 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 U you could uh for instance sort the list keep it sorted uh and that way you can be clever about where you start searching in the list because you know that an item can't be in some uh areas for instance or if you're creating many millions of objects per second you might uh 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 uh time complexity or just efficiency in algorithms you are 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 uh performance is a lot more sensible way of thinking about performance rather than looking at micro benchmarks on JS per 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 it for a paper it will live inside a bigger system a big system that is probably going to be millions of lines of code and because you know humans grow old and our time on this Earth is limited you're just not going to have the time to uh 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 exe what 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 dialogue 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 ing shaving 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 like okay this this uh this view here this is not loading quite as Snappy as it should be uh 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 up front that is is going to be make the application fast instead you have to look at the uh cohesive the cohesive product and figure out which partu 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 uh links to three excellent videos that I would like you to watch the first one is a talk by uh M rff 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 uh something that he calls rail uh which is has nothing to do with rubyan rails it's 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 uh they show how to do rail in uh 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 H 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