Recorded live on twitch, GET IN The Original: • How Slow is JavaScript... The Author: / @simondev758 / theprimeagen MY MAIN YT CHANNEL: Has well edited engineering videos / theprimeagen Discord / discord
in case anyone is interested more about game development and how to avoid garbage collection: look at "object pooling". You basically have pools of specific objects that you create/"destroy" a lot but instead of removing them and let the GC remove them, you put them into a pool to reuse them later on. When creating a new object you instead check your pool first, if there is a free instance available and if yes, you use it. Otherwise, you create a new instance that will be later on added to the pool when no longer needed. That way GC doesn't kick in but of course you require more memory over time. Just a quick and simple explanation, there is of course more to it. Just wanted to share that with you lads if anyone is interested.
I too, am not so great at integrals. Hawking did complex path integrals exclusively using his imagination from the time he was ~10 years younger than I am. Conclusion: I am shit.
It was an interesting video :) there's a whole world of optimization out there that I wish got covered more. As a python developer using mostly Django I have not personally been exposed to a lot of it yet, but it's good to be reading up on comparisons like these once in a while :)
TypedArrays are fun to mess around with until you realize that nobody uses them and you slowly go insane rewriting every library in binary to get a performance boost. Don’t look at web sockets. UDP isn’t possible and most libraries default to transporting JSON. So a single bit flip becomes 100+ bytes.
@@ThePrimeTimeagen WebTransport is a thing, it can do unreliable QUIC streams (basically UDP with bells and whistles), though the standard is in draft, Chrome implementation is experimental, and there are no Rust backend libraries -- the closest is quiche HTTP/3 but you'll need to implement webtransport yourself on top of it
That just goes to show that there is a lot of work needed in high-level high-performance languages. Rust is certainly a step in the right direction, but it's not exactly easy to use. The problem is that for over a decade or so, on the back of exponential hardware performance improvement developers collectively decided that performance is not even a secondary concern, it's a 10th or 20th priority. And that's just usually a very bad decision. It's possible to spend too much time worrying about performance, but nowadays 99.9% of people spend too little time worrying about performance. And languages that are used for boosting developer productivity - don't help either. They encourage trade offs where the resulting code is not only slow but it's also inherently unoptimizable without a complete rewrite.
verry comon to leak objects in the event loop when I used to write unity script in C# it was my no 1 issue untill I understood what gc is. bullets/guns/dead enemies/props that are far away ect ect are all destroyed unless you explicitly pool them
Your general feeling matches mine. JavaScript is easy to write in many ways and I find it highly productive. Performance goes out the window when you start allocating a bunch of memory. Keep your critical paths at a low memory footprint and you get much better performance. You really 'optimize' by minimizing the use of the GC.
I did a quick (not strictly scientific) test on my channel, making a very simple API using SQLLite to select a single record. Where I did ECMA/NODJES vs C++ and sure after some linux kernel tuning the C++ was a lot faster but JavaScript did impress for an interpreted single language interpreter. The memory usage of NodeJS consuming I believe it was 90MB resident vs 5MB of the C++ was more of a concern than the slower processing.
The algorithm comparison is only useful in the sense that it shows any non trivial algorithm implemented in js could have performance within an order of magnitude of C. Prior to V8 this would not have been the case.
Hey... Some input from a Python dev here. I had to develop and algorithm that copies together some images in memory with some rudimentary scaling applied, something that was not really possible via a standard library. It was okay but not fast enough in Python+Numpy - something in the ballpark of 5-10 ms. So I dusted off my C++ knowledge, thougt really hard about data structures. Realized that I could do some trickery with memory remapping and that 5-10ms operation became... microseconds pretty much. It was mad. 1000x optimization. Best case was 100ns because no memory had to be copied (which was the only way to do it in Python) but it could be virtually relocated so "moving" an image from one place to another became a mere update to a pointer (sortof... mmap is cool). I totally forgot how fast C++/machine level code can be if you know what you are doing. Lol
tbf... python is also a crap load slower than even javascript. Python is one of the SLOWEST languages out there. it is the king of easy to learn languages... but it sacrifices almost everything in terms of speed for that simplicity.
@@jabadahut50 Yes it slow, but the best it has libraries that are written in C / ++ and works at near-native speed. It is also great for prototyping and automation.
@@overPowerPenguin to be clear, I wasn't hating on python. It's in my opinion the best intro language for anyone who has never programmed before, and it is still king in data science. Also, it's getting the MOJO superset soon. Soon as that comes out, I'm probably going to pick it up myself.
@@Komatik_ MOJO is going to be to python what Typescript is to JavaScript. Everything written in python is valid MOJO code, but not all MOJO code is valid python. It makes python a LOT faster.
This also ignores how c++ could be optimized further with things like const and pure attributes if he uses gcc. It also ignores the fact if it was a simple expression you could also write it to be constexpr to let the compiler do all the math for you.
Ngl, over the years i've been distancing myself from content creators on youtube. As a front-end engineer, I'm constantly being told how shitty my language is, how front-end isn't all that and real programmers work on the back-end or systems level work. How, everything I do is easy and just for playing around. Frankly speaking it's condesending and discouraging, I've loved your channel because I found it entertaining, but over the last year it seems any opportunity you get to shit on javascript or front-end you will. I'm not saying stop, your videos are still informative and clearly entertaining, but it's getting tiring being the butt-end of jokes and toxicity from the development world. I deal with that enough outside of work. I dunno...maybe I'm being weird and looking into things harder than I should be. Keep being Blazingly Fast!
I don't think Prime really shits on front-end development tho. And about how shitty "your" language is, you shouldn't take it personally. A lot of us code in "shitty" languages bc we have no other choice, and we blame the game, not the player.
@@bakeneko3993 I don't think Prime directly shits on front-end, but in many subtle ways it seems like he, and many of his viewers think they're better than front-end devs. I can be reading this wrong and I don't mean to imply malice on anyone, it's just that whenever he brings up front-end there tends to be conversation around how easy it is to get into compared to back-end. And while it may definitely have a lower skill floor, the conversation sometimes come off as beginners do front-end while advanced devs do back-end. As for the language, it's not that I have some personal attachment to the language, it's the volume of hate. It seems anywhere you go, people will just shit on JavaScript. Very rarely does this channel bring up JavaScript in a positive light. And when all you see everywhere you go is negativity surrounding the tools you use, its starts to feel like a reflection on you (so maybe I am taking it personally). So I don't know, again, I'm probably just jaded. But when you, your field, and the tools you use are constantly being belittled everywhere, it just gets tiring. Then you see videos like these that just add more fuel to the fire and it's not helpful. Like we get it, JavaScript/Typescript aren't perfect and aren't rust. But like even the positive stuff are covered in condescending tones: V8 made a shitty garbage language, a fast garbage language. Or if Typescript introduces a great change for front-end devs, it's: But it doesn't do it the way other language do it, so it's not as good. We can't seem to win or catch a break.
At least he's not comparing javascript with java, I would be seriously pissed off. But he actually have good points for comparisons unlike other people who shits on frontend with no real reason. He also approaches it from someone who actually cares about maintenance, which is a valid point imo. It doesn't matter how fast the language is if you can't maintain the code. I dislike that he uses rust as a good example, but I haven't used rust, so I can't judge. I used C#, Java, and some other bloated languages which made maintenance 10x harder than Javascript. So it's a hard sell tbh.
Funny that you mentioned Microsoft and JScript. I was implementing some tools at work for us to use in JScript that interacted with COM/ActiveX Objects and the Active Directory. Then I discovered some Node.JS packages with bindings for those tasks and I was able to avoid JScript and Windows Script Host 😂 With that being said, JScript and WSH were actually interesting to look at. An ancient relic far ahead of it’s time to be honest.
The advantage of JavaScript is immediate feedback. It's a good place to start learning to code, but if you're serious about game programming, you'll want to take what you learned over to a compiled language.
I think you would have to look at the actual source code or generated assembly to measure the real overhead of Javascript. Just because two api calls look the same doesn't mean they do the same thing.
The issue with these comparisons is that they are usually done by people who dont understand performance. The C code could have been compiled with -flto, -march and -mtune to get a bunch of free performance. Especially -march would make a big difference on the first example, since compiler could easily vectorize the loop.
Transliterations can be fine but you have to do them both ways. e.g. Write JS code, transliterate to rust, rewrite idiomatically in rust, transliterate to JS.
Integrals? @4:00 The C++ code was all run without any mem allocation after initial setup, no? Is it a test of memory access speed. Is JS code operating on an array or a Buffer. Are JS Buffers efficient for anything other than ints? Key point is that it is NOT always allocation and garbage collection. Access patterns can effect performance. If operations are done sequentiall for each element of several column vectors, it matters whether the matrix is stored by column or by row. By column, you may have a cache miss per operation. Port what works, optimize what's needed. If a compiler will improve your code let the compiler do it first before you meddle with it.
Nice to see that someone with certainly more experience than me found typing in typescript a pain! I learned how to do the basic to build a Rest API using TS, but last week I was trying to build a web scraping using TS and I've dropped it! The exactly same code using cheerio library using JS was working fine but in TS kept showing a stupid type error, I've tried about 5 different types for the same property but it didn't work!!!! I'm aiming to be a front-end, but I'm in love with programing in general, so other type languages aren't that painful to code? I just know JavaScript and a bit of Python.
@@nerdError0XF I don't have the code anymore, I ended coding using next js with JavaScript instead because my deadline to do it was till yesterday, it was a technical challange for a job application , even chat gpt couldn't help me with the correct typing LOL, I was using Cheerio and couldn't type it correctly, but then I changed to JavaScript and Puppeteer Cluster would be more appropriate for what I was trying to do.
Type errors when the untyped code works fall into a few different camps: * The types for the library you're using are crap. Very common. Patch the types and submit a PR, I guess? * You do actually have a type error, but only in exceptional circumstances. This is often just adding a not null assertion (!) or adding a basic guard condition so typescript knows you're not in one of those. * You or the library are mixing together features that confuse typescript, for example overloading and parameter extraction. Often not much you can do in these cases other than ugly casting or repetitive code, but it's pretty rare. * You've actually found a situation that Typescript doesn't support. There are a few of these, but they're often getting into incredibly complex typing situations. The most common one I hit is parametric values, eg you know each item in an array has a function to create a value and a function to accept a value of the same type, but the type can be different for each item.
@@SimonBuchanNz it makes sense, I need to get used to typescript, I've been refactoring some old projects recently and didn't had a chance to play with TS again. I'm currently striving to build my portfolio web page and maybe I'll do it using TS along next js as soon as I finish styling my recipe app
Javascript was not build to conquer the world, but it did it anyway. Only compititor it had at it's core domain was Java Applet, but life is too shot to write code in Java so JavaScript it is.
I still like Larry Wall's approach: Programmers' time is more valuable than RAM or CPU. For any real life application (not high performance gaming or simulating the behaviour of plasma in a fusion reactor), only the order of complexity truly matters. If a compiled version is 10X faster than an interpreted version of an implementation: So what? Computers are faster than the user, anyway. But the fact that writing down something in JS or Python is usually done in the 10th of the time that you would need to implement the same stuff in C++ or Rust, does matter. However: From my personal observation, if you're dealing with a high number of datasets in JS, don't encapsulate them in objects! Use simple arrays, wherever you can. Going through the abstraction layers actually increases the complexity of the program in JS (though not in compiled languages like C++).
I agree if we’re talking small to medium businesses with applications on end user pcs, but the hyuge internet world like the amazons or Netflix servers, 10x is having to buy 10x fewer servers, power, etc. It really depends on the scale you’re working in. That said, even at my small scale, 1 minute vs 10 minutes to get an answer saves someone going for coffee three times a day.
Ive just build a crawler/scraper in nodejs which makes heavy use of xpath and because it was slow I had to implement it in PHP which was at least 10x faster (xpath nodejs ~50ms, php8.2 0.025ms, 1 expression) and I did not need any external libraries.
with this logic let's test Pypy (JIT) and also cython for python and woah python is super duper fast as well let alone most lib are in C/C++ so you are invoking C/C++ and sometimes Assembly code
Your comment about allocation is a good one. Testing out mathy inner loops isn't really going to give you a good idea of the relative speed of two languages, and the "JITs will just get better" is misleadingly true. There's an S curve of performance improvement, and further improvements are going to be tiny. The easy things have been done, and the hard things are nearly impossible.
I saw some people discrediting the benchmarks because they were from a game development standpoint. To those people I say one thing: You'd be surprised how many fields of software engineering game development covers - especially online games. And you'd quake (heh) in awe when you realize that most of the technologies you take for granted like streaming a movie from your couch at night comes from the (sometimes) insane requirements and standards of game development. Also you guys completely missed the point. The benchmarks was of basic math operations and computers are build to do exactly that. So if your language does math bad, it bad.
Fun fact: That comment at the start - the first one to pop up - was mine. Admittedly, I was being sarcastic, and I told the original creator about that when he released the video, and he seemed amicable.
4:00 well dont allocate or deallocate. That's not very C style. Here's the javascript benefit: var x={} x.y=1.0 100ms and blocks multiple threads ez win for js
Worth pointing out, just because it's faster now doesn't mean it's not bad anymore. I don't care how fast your Brainfuck compiler is, I'm still not gonna program in it.
Looks like yt is recommending everyone the same channels here. Just found SimonDev yesterday, and watched hours of his vids. Same with most other recent primereacts.
JS lacks performance (speed if we measure it) but least it makes up for it in productivity. I personally use a few languages (JS included) and the way I view it -- use JS for what you need it for. Example I work for a small start up with few employees, we don't have a bucket ton off money but hell we can pump out what our clients need -- bring in developers that can pick up on the codebase really quick and at the end of the day it does the job we need to do. Sometimes I think people miss that concept when looking at the language. Sure it's being used for things it probably shouldn't be used for but that is the beauty of programming and the ecosystem developers before me have created.
@@maddsua I guess the second step really depends on the project + client needs. I say this coming from my personal experience -- it depends on a lot of factors (money, delivery, contracts, etc). If I have a customer with a JS backend who now wants a more performant solution and that's the requirements (go faster) and it involves me getting paid than sure 😊
04:53 YES, v8 seems too not gc enough if you have node/deno long running script and you have code to report bad performance (like logger) call gc() in there (need --expose-gc)
I think you have the wrong take on how "hard" is to write those complicated operations and those "stupid typing that you have to do" with Typescript. The think with JS without TS is that you cannot tell if you did it right, you think you did, but as time tells us, code in Javascript is always wrong, and the worst part is we know that when the code is already in production. Typescript can be far better, I give you that, but JS code is 99% of the time ready to break with the smallest change. It always works at first try, but you need the smallest change to break everything.
When you don’t know how to write proper javascript you spit out shitty comments like these. Typescript doesn’t work in browsers, it’s just Javascript. I have a sharded nodejs cluster (70K LoC) that gets 800k requests per day and a rust microservice (25k LOC) deployed that gets around 100k hits per hour. None of those broke on production. Guess what? Its you who doesn’t know how to write proper Js. Tons of software was shipped before typescript existed. React was 100% javascript before 2018. They had to enforce typescript because of people like you in their team. They simply don’t learn to be better, all they need is some kind of helper tool to help assist them in every thing
@@Barnardrab They are not if someone have experience with statically typed language. If someone has started their coding with scripted language like JS then God save him.
@@nieczerwony My first 2 programming languages were Visual Studio and then Java. They were intuitive to me but I had a hard time picking up JavaScript.
@@Barnardrab My first were assembly and C/C++. Then Java. JS was easy for me and it has its use for sure. I think biggest issue when it comes to JS are the libraries as people try to focus on using them rather then understanding the basic JS. Like people going mad about full stack today and stuff like React +Node.y first stack was LAMP and I should still prefer PHP over Node, but from let's say IoT perspective Node is way better for "real time" over network solution. As engineer I learnt that we just need to pick a tool for specific task, and I don't demonize any of it. I always like to learn new things and solutions.
just imagine how much energy could be saved, if we banned javascript. Energy wasted because it is slow and inefficient. Energy wasted because every single computer has to jit compile the mess every single time the crap is run. It is mind boggling. Nothing of worth would be lost, if we banned javascript. Apart from some ad slingers having to ressort to old school untargeted ads maybe.
