In Web Development
How to make TypeScript Blazingly Fast (JavaScript/NodeJS) - read the full article about Node Js update, Web Development and from ThePrimeagen on Qualified.One
Youtube Blogger
gatsby blazingly fast seven react libraries blazingly fast blazing fast javascript the promise of every javascript library but youre probably asking yourself how do you make fast that which is slow astute question and observation so you cant really i mean technically javascripts slower than a lot of other languages but you can definitely make it fast in comparison to itself blazingly fast but how do you make it faster well its actually a little bit surprising some of the techniques you can use to make your javascript applications faster so im going to walk you through how to actually do it how to actually make javascript basically fast so what did we build and by we i mean me building the actual application and of course degenerates on twitch explaining to me what ive done wrong and what i should be doing wow so zig has zero macros and zero meta programming yet its still powerful enough to express any complex program in a simple and concise manner what are you a walking pamphlet get the hell out of here so what i did build was actually a pretty simple game server that runs at 60 ticks per second and we measured how successful we were at maintaining 60 ticks per second the game starts off with two players each are given a fire rate its obvious that one of the fire rates is slower therefore one of the players is going to lose every single time after receiving a ready up command and a play game command the players will start firing at each other every 200 milliseconds which means that the slower firing rate will be disadvantaged and eventually will lose the game the game looks like this we start with the ready state once both players are ready and started firing we enter into a loop we check for any fire commands and create any new bullets if needed we check for collisions and move the bullets according to how much time has passed since the last loop then we check for an end state to the actual game so this should give us a pretty robust place to be able to test out some performance improvements so lets get started lets try to make this application a bit more blazingly fast no karen blazingly fast is not a euphemism i mean i guess it kind of i mean i get i get it kind of is yeah okay reasonable i will stop saying that you win karen ill update my vocabulary blazingly fast the must-do first step to improving any performance is to get a baseline measurement what are you trying to improve if you recall from earlier this was our game loop now every single time it runs we may get some good loops but sometimes we get some bad loops meaning something happened that caused it to run a little longer than expected and of course we can take all these times and we can actually bucket them together therefore there are seven good loops there are two uh you know kind of exceeding ones and then one that gets even further exceeded now with the actual data that i was capturing i had many more buckets to fill in and of course we would have somewhere between 200 concurrent games to 800 concurrent games being played at once on a linode.com/prime single cpu instance so that way it was, you know, a fairly repeatable experiment a little side note you shouldnt run your experiments on your own computer just because your computer has a lot of things happening so i always have an instance that is at least more quiet and more predictable than my computer with the base implementation no performance improvements at all i had about 96.6% of the ticks actually considered good ticks within 16 to 17 milliseconds the rest after that were comprised of mostly 19 to 20 milliseconds after that a very small percent for anything above that once we increased to 400 concurrent games or about 800 active players the percentage dropped quite a bit even more so once we got up to 1200 and at 1600 less than half of the ticks even were considered good so the typescript server fell apart pretty hard as it got under load so now we have a goal just simply make this blue bar bigger again karen not a euphemism or just trying to make a big girthy blue bar okay totally normal totally normal one of the easiest ways to understand whats happening in your server is to do a flame graph now with node its pretty simple you pass a simple flag --perf-basic-profs run perf throw it through the little perl script and of course generate the flame graph and boom you got yourself a flame graph now how do you read this thing well effectively how perf works is its like taking a stack trace hundreds or thousands of times a second it takes all those stack traces sorts them so that the x-axis isnt meaningful in a time sense meaning you couldnt say okay this one call over here is 45 milliseconds no what it is instead is its proportions so when i look at this i can see that right here this is 45% of my program i am within this function so its actually a really easy way to see what is taking a long time to run now when i look through a lot of these peaks what im going to see is a lot of like e-poll so probably not going to improve that part of my program i see tcp probably again not something im going to improve node internals when it comes to firing timers node internals when it comes to reading streams all of these im probably unlikely going to improve this running time my application really consists within this stack right here so lets look at this top one specifically it is called collisions its taking 20 percent of the time when i can do a little control find i can do collisions and in case it appears else in the stack ive raised myself up just so you can see this down below this says 21.5 percent of the time i am in this function i know what function this is and i know probably how to make this faster so this looks like a great place for me to try to improve the reason being is that i just did a simple n squared algorithm take every single object and just compare it to the rest of them so what i could do is break up player ones bullets to player two bullets and only test against each other because player one bullets will never collide with each other player two bullets will never collide with each other its only this direction so easy win all right so i re-ran the program and what i see is that my collision went from 21 and a half percent of the time to only eight percent of the time this means we should see an effect on this we should actually see our program run faster at least i would assume so at this point i made a pretty decent sized improvement here youll notice that this side of the graph actually got larger meaning that we have more time to be able to do operations that i cant quite control their running time by reducing the amount of time that i can control so i re-ran the exact same experiment and what i see is a dramatic improvement in the amount of blue ticks in both the 800 connection and the 1200 connection comparing it i see about 62.4 percent of the time im in the blue bar section or the well-behaved ticks 16 to 17 millisecond in the original server versus 72 percent of the time so this is definitely better all right so if you dont know how to run perf i will include the commands in the readme on the repo https://github.com/ThePrimeagen/tyrone-biggums do that free five oclock crack giveaway again yes yes twitch did choose the name okay stop judging me all the links will be down below were you surprised at how much of an improvement we got that was a decent 10% improvement by fixing something that was pretty trivial to fix often what youll find is that youve made some pretty simple mistakes when you look at a flame graph but lets try to improve our server but on a completely different dimension something that might surprise you you can run node with the --inspect flag and youll be able to see a memory tab in the chrome debugger by going to allocation sampling you can measure just like perf traces memory being created instead of cpu being used theyre identical in how to read the graphs so this one you read it of course as this takes up a lot of memory this takes up some memory this takes up a lot of memory the total amounts of memory probably dont really matter because its not quite correct its a sampled amount but its again you just look at portions and can you improve it proportionally youll notice right here that looks kind of crazy about 33 percent of the time were generating all of our memory from a place called processMessage now what process message does is it takes in a fire command from the websocket creates a bullet and adds it to the world i was a little bit surprised seeing that and when we look at our flame graph only 2.7% of the time are we in this function so its not like its a heavy cpu function but it is a heavy memory generation function along with that we generate a lot of memory just listening to sockets so if we could improve that along with how we keep stats for game the players we create we could see a much better performance in our server so were going to improve this by creating memory pools effectively a memory pool allows you to cache an object and reuse it over and over again since im going to create literally thousands of bullets a second i should probably just have a pool these short-lived objects can be created once and just used over and over again if i can just simply reset their position and their direction so to create a memory pool i created a very simple ring buffer if youre unfamiliar with the ring buffer ring buffer allows you to have a fixed size array where you have two pointers one where you need to insert at and one where you need to remove at and as you insert and remove they go around eventually you could have your insertion catch up to your removal at that point you need to create a bigger area to store your items or the other direction your removal catches up to your insertion then you just need to create a new object to be held by the memory pool now the dangerous part about doing this is you have to manage your own memory meaning you cant just let the bullet be garbage collected you need to manage its lifetime (RUST BABY) when i create a bullet i actually have to remove it from the pool update all of its positions and set its direction and every single time i need to remove a bullet i actually have to call the cleanUp method and make sure that the bullet re-adds itself back to its own pool which also means when we tear down our world i need to remove all the bullets and go one by one through the list along with removing the lists themselves releasing the players doing all of that so this can actually become quite cumbersome and easily you can mess this up but the effects are incredible so heres the previous one now notice if you look at this graph this section pretty much over here represents ws the blazingly fast websocket library and you can see some more of it right in here as well so about 40 percent of it is comprised of just ws memory and stuff when we look at the new version youll notice that process message becomes nothing i do have to json parse so of course thats gonna have some effect but on top of it the ws memory thats being used is now like 66 perof the program weve really slimmed down our program to be as optimal as possible now before i show you the results what do you think is going to happen will we actually be faster or is all this memory management not gonna improve anything because you could defeat the compiler right jit may not be able to run i have no idea the javascript engine is a very complicated piece of machinery what you think may make it faster may make it slower so just to remind you about 64.2 percent of the time we had good frames at 1200 connections in our base implementation now when we look at our memory pool we actually see that 74.7 percent of the time we have good ticks this is actually a bigger improvement than our hot spot implementation for me this was kind of surprising i did not think it would be a better improvement it didnt really show up in flame graphs the way i thought it would i thought the fix was kind of obvious so for me this was a bit surprising how good it was and something else that was actually kind of surprising is that youll notice that the memory used our base implementation was getting up over 200 megabytes at 1200 players versus right around 110 megabytes for our memory optimization look at the memory much smoother barely grows the average is literally twice as much for our base implementation versus our memory optimized all right so for the final experiment i played a hundred thousand games with the base implementation versus the final implementation both the memory and the hotspot improvement to compare the differences of course when we get into the final one right here were looking at 46.1 percent of the frames are within our acceptable range that means over half of the frames were 18 milliseconds or higher which is actually pretty surprising like our server was really slowing down all right so lets look at the exact same graph at 100 000 games played 54.1 percent of the time the ticks were good which is actually an over 20 percent improvement compared to the base implementation at 1200 connected players its 75 percent versus 64 percent another huge improvement okay yeah come on in twitch okay yeah oh okay yeah youtube yeah you can come in too i get it you guys want Rustlang and golang yeah well heres the deal like i said last time give this video a like do a little comment let me know that you like this content because once again if you guys dont interact with me how am i supposed to measure the improvement here okay come on as you can see i like graphs so if youre not providing me the information i cant graph it and of course youtube you want to see this created live you gotta head on over to twitch i mean look at twitch what a nice character huh you like him well guess what you can hang out with twitch all day long
ThePrimeagen: How to make TypeScript Blazingly Fast (JavaScript/NodeJS) - Web Development