JavaScript performance is weird... Write scientifically faster code with benchmarking

[@pokefreak2112]

The benchmarks should really also include memory allocations. array map/filter create new a new copy of the array every time so even if they look decent on isolated benchmarks they put load on the GC which may introduce lag spikes if you spam them too much.

[@lbgstzockt8493]

And memory reads. I would rather do ten compares than one RAM read.

[@CTSSTC]

We should just transpile code and let it choose the best for loop :P maybe allow an annotation for expected loop size or even better let the runtime figure it out and optimize over time due to it running its own measurements ;D These are things we shouldn't be worried about when it could potentially be automated. We should instead be focused on conveying expectations.

[@rothbardfreedom]

As a counter-point, memory is something you can buy and it's cheap. Time, on the other hand, can't be bought.

[@pokefreak2112]

@@rothbardfreedom Sure good hardware lets you write inefficient code and have it still run fast, but that's not an excuse to be ignorant. The entire point of benchmarks is to gather performance information. The more relevant information you can gather the better you can make decisions (even if that decision is to waste memory because it doesn't matter in your circumstance)

[@Devin-u8f]

@@rothbardfreedom he/she is talking about time though

[@AbdelhakOussaid]

Shout out to those developers, like me, who write gibberish and it works!

[@ARandomUserOfThisWorld]

I don’t just use a DB… I use an excel spreadsheet, and when it runs of space(which is hardcoded at like 1mil rows), it creates a new spreadsheet with a new ID which is specified in the filename and nowhere else, and use that, all of those files together, instead of a DB. And all of them are .xlsx files btw.

[@vikingthedude]

@@ARandomUserOfThisWorld awesome. I use fopen

[@sad_man_no_talent]

@@ARandomUserOfThisWorld I just use a json file

[@everythingisfine9988]

💪👑

[@Alfakatt]

Us

[@eliasepg]

7:52 "you're good enough even when you're not at your best" love this statement, very deep

[@allesarfint]

0:24 "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."

[@Hector-bj3ls]

Also, if you don't architect for speed, you won't get it. You won't be able to come along later and "optimise the hot spots". Because that's not how applications work. There's this idea that you'll have one or two hot loops l, and you'll just have to focus on those. If you've profiled any real applications you'll see two things: 1. One random getter is causing all the problems. Fix it, and you arrive at point 2. 2. Everything is equally slow, but not really slow. Like everything takes just a few milliseconds and there is no hot spot.

[@kasper_573]

The most important thing to measure is the performance of your application, not your modules or functions. Measure those once you’ve detected a performance issue with your app, and need to drill down as to why and fix the issue. A slow sum or sort is usually pointless to optimize if its impact on your app is negligible.

[@afraid2letgo]

Louder!!!

[@erikjohnson9112]

Quicksort is not a stable sort. With a stable sort routine equal items will have the same relative order compared to the original. Quicksort does not have this feature. Most of the time you might not care, but that IS a difference worth noting.

[@dentjoener]

Thank you, and with sort getting faster on strings, it's probably trying to minimize comparisons, something TimSort does in Java and Python, because comparing is more expensive. Plus TimSort is stable.

[@wi1h]

@@dentjoener python doesn't use timsort anymore, they changed to powersort in 3.11. still stable though

[@sahilaggarwal2004]

The set example is not really accurate. Although I agree that it definitely provides performance benefits over Array.includes() in case of large data but while benchmarking we must also include the one time overhead taken to create the set as we are originally dealing with array data type.

[@aleksander5298]

that's why small array is faster than small set, but big set is faster than big array, you edgy boy

[@Slackow]

@@aleksander5298 big set is only faster if you actually keep the set up to date, and use it for multiple times, if you remake the set every single time then it's slower.

[@beyondfireship]

I disagree. The array is already in memory, so the Set should be too. The objective is to "find an element", not create the original data structure. One-time setup is insignificant on a task that runs millions of times. But just for fun, recreated the Set on each benchmark run and it still performed 20x faster.

[@aleksander5298]

@@Slackow why would you remake set lmao are you dumb? just use set instead of array, ez, you have skill issue or what?

[@sahilaggarwal2004]

@beyondfireship yeah that's what I said, set will be faster, no doubt in that. But the performance gain is not a million times faster if we consider the time to create the set too, and that's what I felt was inaccurate.

[@johnvomberg450]

The introduction was the most interesting part of this video.

[@k98killer]

Technically, there is a fifth way to loop: `for (let i=arr.length-1; i>=0; i--)` or `for (let i=0,l=arr.length; i

[@jmvr]

Running the benchmark on my PC, the traditional loop can run 14,680 iters, but the reverse loop only ran 14,570 iters. It's practically the same speed, so I don't think it really matters. I'm guessing that it's a set value that only gets updated when something is added or removed, rather than recalculating every time it's called. Weirdly enough tho, the for..of loop runs 14,840 iters, so it's somehow faster despite being slower in this video. I also added for..in for good measure, and it ran 247 iters, so it's clearly the loser lol

[@k98killer]

@jmvr yeah, the reverse js loop is an arcane optimization from a more civilized era.

[@almicc]

I would hope for normal array types in Javascript that there's no difference between saving the length ahead of time and checking it every time. Feels like an ideal place to optimize on the runtime's part. But if your length is computed by an actual function, then you should definitely save it first since the runtime can't know if your function has intended side-effects.

[@k98killer]

@almicc yeah, browser runtimes used to be pretty unoptimized. I haven't run any benchmarks in Firefox in a while, so idk about how well it performs, but V8 has optimized this.

[@NutchapolSal]

getting array length in javascript takes constant time, it's a number that's stored with the items, not calculated on the fly

[@cosmiclattemusic]

can't unsee NODE transitioning to DONE 😭

[@k00lmoh]

you mean DENO

[@orcagaming2143]

No he means done but it'll be oden before it because done😊

[@jackiedo7370]

NODE -> DENO -> ODEN -> DONE 🎉

[@danielschmider5069]

sort(NODE) = DENO

[@jakeave]

We've been able to squeeze out more by declaring i before and not using a lookup for the length. I know it sounds terrible, but it's ever so slightly faster. let i = 0; const len = arr.length for (; i < len; i++) Use at your own peril.

[@jerichaux9219]

I've done similar. As long as you maintain ownership over the array (to ensure the length isn't suddenly shorter than it was when you'd began), this is fine.

[@JasminUwU]

​@@jerichaux9219 That sounds like an absolutely horrible bug to discover

[@S7hadow]

I can see .length as having a slight overhead and so making a difference over a big number of loops. But the declaration of i doesn't seem logical to me as that part of the for loop is only run once. Guess I have to try Deno bench now

[@rumfordc]

@@S7hadow i believe the declaration is because scoping rules for loops are different from the rest of the function in javascript. the interpreter also needs to differentiate between which type of for-loop it is, which the semi-colon disambiguates immediately as opposed to reading the entire declaration before knowing which type of loop the declaration is for.

[@rumfordc]

also making that a while-loop should be faster than a for loop

[@zeikjt]

8:02 Yes, yes, noooooo! Using something like Deno bench doesn't tell you where bottlenecks in your program are! You need to profile your actual code in-situ. Then if you prove there's a bottleneck somewhere and it is affecting the performance of your program in a meaningful way then you can use bench to try and find faster alternatives, but then you need to test it again in-situ to make sure it actually performs better. You might have misunderstood the shape of the data, or the shape of the traffic to your code and find that your speed up didn't actually change much. You can't always test these things accurately synthetically, and you won't know it until you try it with the real thing :)

[@r5LgxTbQ]

5:20 no fair, your benchmark doesnt account for the compute power to create the Set in the first place. You're not starting from the same place so it's not an accurate comparison

[@zeikjt]

Ideally you'd be using a Set from the get-go instead of an array, then you are starting from the same place. But if it's an all-at-once allocation instead of incremental then sure. This is why benchmarks are not ideal, test your real code to find actual bottlenecks and then you have the real situation.

[@AlexGoldring]

This is called "micro benchmarking". Problem is - they tell you how fast your module runs in isolation, but not as part of the whole. Example: you have an algorithm that just fits into your CPU's L1 cache, it runs pretty fast, but if you include it into a larger program, suddenly it's very slow because it's not in cache - something else is. I've had many cases where I would benchmark something to perfection, only to find out that in production performance is opposite of what benchmark says. I think microbenchmarking is useful, and it's fun, and it helps you build some confidence about your assumptions. But it's very rarely reliable in the context of a larger application.

[@V3racious3]

This Deno commerical brought to you by Deno.

[@rawallon]

A Deno a day keeps the exception away

[@Bayzon08]

Learning during an 8 minute ad for a Deno course, love it!

[@ErazerPT]

As pertains to the first example, repeat after me children : I shall NOT microbenchmark things where the function call overhead overshadows the work being done by an order of magnitude or more. Seriously, this is such a common thing it should be a meme for all intents and purposes. Now, show us a run where the work being done doesn't amount to "basically nothing at all", ie, something a tiny bit realistic...

[@almicc]

I think in crazy situations like using JavaScript to essentially sort data as an API, which is 99% of all web services, the function overhead does matter enough to the point that devs need to reduce the use of overhead. I also like to consider the fact that in apps with large enough user bases, the difference between sorting being in the scale of ms doesn't matter to individuals, but if you consider the large scale power consumption, that difference could literally reduce energy consumption to a significant degree. Consider that downloading metadata on NPM is unironically a million dollar problem that costs a lot of energy and disk space when the correct solution is to just copy paste the function you wanted.

[@almicc]

Just as an example, I did implement an improvement to an AWS system where we simply descale servers when there's nothing to do, and removed a bunch of legacy promise/lib code and used native promises and traditional for loops. We went from several servers running 24/7 to a couple running for two hours a day. I'm serious when I say the only changes were traditional for loops, native promises, and removing a bunch of lodash/ other lib code. JavaScript is quite literally the only language where function overhead is truly the worst performance impact.

[@ErazerPT]

@@almicc Sorry if this sounds harsh, but you can do all that, but cant READ? Function CALL overhead, not function overhead. The cost of calling a function, not the cost of the function runtime. With simplistic code like in the video, the cost of setting up the call and invoking it can be statistically significant, as opposed to vs a function that actually does some realistic workload. Same issue with setting up threads for parallel work, using LINQ, etc. The more work the function does, the less the cost of calling it matters, and obviously vice versa. And the code used in the example will 100% sure run straight from the CPU cache, grossly exaggerating the results. As for the JS particulars, well... JS has a knack for making things worse, but this isn't something JS specific, it's a "general benchmarking" issue, no matter what language you use.

[@BritishBagelGaming]

5:35 , thought it would be fair to include the initialisation of Set from the array within the benchmark, no?

[@Daniel15au]

No because you'd start with a set from the beginning, if it's the best data type for your data.

[@nano_sweet]

I thought Set initialization should be included in the benchmark, since the problem stated at 4:43 is "finding a value in an array". Although I feel like for large arrays converting to a set would still be faster.

[@Daniel15au]

@@nano_sweet I think that's likely a mistake in the name of the benchmark, and it should be "finding a value in a collection".

[@masterserge]

You can also accomplish this using a while loop which should be the fastest way. let arr = [1,2,3,4,5]; let sum = 0; while( arr[0] != undefined ){ sum += arr.shift(); }

[@RandomGeometryDashStuff]

06:49 unfair test! `[69,420].toSorted()` result is `[420,69]` but other sort functions output is `[69,420]`

[@noirsociety]

"Languages that try to disallow idiocy become themselves idiotic." -- Rob Pike

[@okie9025]

sounds a lot like rust to me

[@netssrmrz]

great quote. sounds like React to me.

[@randomuser66438]

​@@okie9025Here they come

[@shellderp]

The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt. It must be familiar, roughly C-like. Programmers working at Google are early in their careers and are most familiar with procedural languages, particularly from the C family. The need to get programmers productive quickly in a new language means that the language cannot be too radical. Actual Rob Pike quote

[@Sevkavic1]

@@netssrmrz React isn’t a language but just a view library though, with no strongly typed features (which is a synonym to trying to avoid idiotic mistakes), of course if you not being forced to use ts

[@rothbardfreedom]

That's why TDD is crucial: If you can make produce your code driven from a suite of tests, you can 1 - measure the code and 2 - safely change it. If you don't drive the code from the tests, (2) will always be a shoot in the dark.

[@thepaintedsock]

Great video. The for loop can be sped up even more if you create the for(let i=0, len=arr.length; i < len; ++i)

[@callbettersaul]

5:06 Is this not O(n^2), as it's using includes in a loop, which in turn loops every value of an array? Or is it O(n) just because the arrays are different or something?

[@Blafasel3]

It's O(n*m). (10000 * 1000) The issue with the set lookup example is that it didnt include the extra overhead for indexing the set - which is O(n) because it has to index each element. On the other hand, the other example in the scenario is actually O(n*m) because you are iterating twice, once over the array with the elements to search for and once for each element in the base list. So the errors in both examples kind of cancel out. Still goes to show that O(n) notation is confusing af and should only be use if absolutely necessary.

[@DeaconuDanAndrei]

You can actually make the for loop even faster by "caching" the length like this: for (let j = 0, len = testArray.length; j < len; j++) { // loop body } But, it would only make sense for very large arrays. Props for the video and course.

[@mmanomad]

Love seeing more Deno videos!

[@patric_forreal]

Using the SET trick to sort is much like using hash map ✅

[@robinmitchell6803]

5:16 -> Did you include the time to organise that array? If not, you can't compare the two.

[@tomasprochazka6198]

The initialization of Set takes some time though, should be included in the benchmark too

[@zeikjt]

Only if the Set is temporary, if you use a Set instead of an Array altogether then it's the same thing.

[@piff57paff]

Even then, there is more overhead during insertion. So you still need to look at it holistically.

[@zeikjt]

@@piff57paff i suppose it does depend on whether the data is always created in bulk or incremental. This is why you don't find bottlenecks via these kind of benchmarks, you time your real code so you know the situation

[@Daniel15au]

​@@piff57paffyou usually create a collection once but use it many times, so insertion cost is generally not as important as the cost to use the collection.

[@euseikodak]

This definitely is the kind of content I'd love to see more, even pay for it! I'm not very interested in Deno though, but if you launch a broad course in which you pass on important concepts like this one, please do advertise it and have my money 💸💸💸

[@turun_ambartanen]

at 5:40-5:50 you say that a JS set is like a DB index. Is it really? I would have expected the set to work on hashes, but the index to work on a balanced binary tree.

[@ence7846]

This is an implementation detail but Set are just binary tree in js, like Map

[@turun_ambartanen]

​@@ence7846Ok, that Confidently ( turns out, Confidently Incorrect) statement got me to do the research myself. Sets (and maps) in JS are implemented with a HashMap, not a binary tree. The relevant code is in v8/src/objects/ordered-hash-table.h > HashToBucket

[@lwinklly]

Anton mentioned 🎉

[@MelroyvandenBerg]

Yes he was. I'm recently creating quite some PRs for his tests 😅

[@Dominik-K]

Rob Pike mention ftw

[@ansgarschurmann6177]

One of your best videos! Thanks a lot!

[@macerdough]

Yearly Beyond Fireship Upload les go 🔥🔥

[@B1aQQ]

It's a misleading oversimplification to say the type of loop doesn't matter if the array is small. It might not matter if it runs infrequently. But if it's a part of a high traffic path, then you can have hundreds of small loop executions a second and that would mean the small differences can compound into an impactful performance hit.

[@bgill7475]

For loops are great, it’s always funny to me that people say it’s outdated when it’s just amazing and fast.

[@Vulcorio]

Help me out, guyes @5:14 he says that we can create a set and then run set.has() method to check if value is present, and .hes itself performs a million times faster, but he only benches the preformance of .has() vs .includes(), and misses out the part where he needs to create a set from an array. I'd assume array -> set takes more time than simply finding a value in an array, given that the input data is an array. Or did i miss something?

[@JJJMMM1]

5:40 the analogy between database indexes and O(1) Set lookups doesn't make sense to me. Most database indexes are stored as B-trees or B+trees, and the lookup complexity there is O(log n). So either the time complexity of a Set lookup is also O(log n), or the Set is actually stored as a hashmap - which is what I would've guessed - giving you an average case of ~ O(1).

[@CottidaeSEA]

Premature optimization is no good, but don't write code with poor performance if you know it'll process a lot of data. It's not premature at that point.

[@amine7]

How else would you later make your service 5x faster and create a blog post and a youtube video bragging about it?

[@CottidaeSEA]

@amine7 Could do what a colleague of mine did. Do a big import, loop through the entire file and compare for every potential matching item in the database. That way I could improve the performance by 1000x by just using a hash map.

[@unformed]

Just add a wait(1)

[@aleksander5298]

In the sumUsingForLoop you should make arr.length a separate variable to make it faster

[@dromar853]

at 5:10 for the arr-includes test: Set has a `intersection(B)` method. this should be even faster.

[@dei8bit]

what I was most curious about is the correspondence between the sounds and the iterations of the sorting algorithms.... very nice and weird

[@karamuto1565]

Using a "Set" for checking if an element is contained in an array is probably mostly usefull if you do this over and over. But in those cases I mostly want to get a result from that check so a Map will usually be the structure of choice. Sets are still good to remove duplicates though.

[@Silver-fh4fb]

Anyone else get these weird out of order frames in some of his videos? At 3:34, the third line dissapears and appears again (you can see it when you go frame by frame with "," and ".")

[@spezialissimo]

The same happens to me

[@ColinRichardson]

2:46 I don't really wanna install Deno, JUST to test this, but Anyone know the performance difference between for ( let i = 0; i < arr.length; i++ ) vs for (let i = 0, length = arr.length; i < length; i++ )

[@vighnesh153]

In the bubble sort implementation, I noticed that you were swapping variables using the array destructuring syntax: [a, b] = [b, a]. For small arrays, this is fine, but if the arrays are large, then creating a new array allocation just for swapping might also cause GC which will slow down the entire bubble sort impl. For benchmarking, it would be better to swap the variables the tradition way by creating a temp variable.

[@case451]

Log things you care about with timestamps, always include millis, ensure clocks are synced if different steps run on different machines, log latency in nanos for things you really want to drill down on, and use good log-analysis tools to understand system-wide latencies. Benchmarking individual functions or sections of code is only useful after you have identified that code to be a major bottleneck in the overall system.

[@netssrmrz]

great video. would love to see a version for frontend.

[@gulllars4620]

With experience, you can often tell places or things that CAN be problematic if done wrong, so you up-front in design follow rule 5 + 3 (that's the order to think of them) to speculate on which data will my code be working on, what range of sizes will it have, where is it (RAM, disk, over the network) and how can i make sure i get the stuff that needs to be local there in a good performant way by the time i need it. Then you do educated guesses whether each is this a big or small set and how they interact. If you know your problem space that's generally easy, and anything under 1K-10K elements are small unless you do stupid stuff like nested foreach lookups (like demonstrated here). Unless you're making a physics engine, or do stuff over a network, your data processing is what will take time. Foreach looping over a network is a crime against your CPU and user. And in accordance to 1, 2, and 4: Verify your speculative assumptions with some debug timestamps and benchmarks, and unless you're working on 100K+ items or cross products, don't bother thinking about instructions and cache hierarchy (if you do, then look at those where you data volume and time spend actually happens and iteratively tune those). Most my code has been slow because of UI libraries doing stuff that really shouldn't be taking that long, ORMs doing ridiculously stupid things with predicates or accesses over the network, or unoptimized data structures where volumes ended being significantly larger than expected (gotta love tuning those for easily 50-1000x perf boosts in a tuning session).

[@deatho0ne587]

forOf is my goto now a days for looping. One it is one of the faster and it is also easiest to think about in pseudocode.

Deno is becoming awesome

[@vaisakh_km]

All thanks to bun.. Our cute little deno couldn't haddle the competition from Js's round buns XD

[@RustIsWinning]

​@@vaisakh_kmHahaha nice copium from the runtime with 500+ segfaults 😂

[@thatsalot3577]

​@@RustIsWinningyeah but you can't deny the fact that they're the reason why deno is atleast trying to do better because pre deno 2 there wasn't much reason to use it. And I find bun to be still pretty good for servers and web sockets

[@RustIsWinning]

@@thatsalot3577 Wrong. Yall just living under a rock and getting benchmarkbrainwashed by twitter influencer andys who are still stuck with the worse ecosystem lmao

[@vaisakh_km]

@@RustIsWinning there is no wrong or right... compatition is always improves the products.. period. I don't and never says bun is better than deno... deno will be always better at compatibility due to v8 engine

[@RandomGeometryDashStuff]

06:22 does `[result[j], result[j+1]] = [result[j+1], result[j]];` create and iterate array?

[@codyrap95]

It creates a temporary array in memory and then destructures it as it's easier than creating a third variable to store the temporary value of result[j]

[@AdamHillbilly]

Make the traditional for loop even faster by assigning a const to arr.length before the loop 🚀

[@pirixyt]

You forgot to loop with a while loop.

[@brandongregori995]

Probably the exact same as a for I loop

[@jakobsternberg1807]

Yep: var L = arr.length; while(L--) console.log( arr[L] );

[@Daniel15au]

It compiles to essentially the same bytecode as a for loop.

[@jakobsternberg1807]

@@Daniel15au Compile? My javascript usually runs in a runtime environment.

[@Daniel15au]

@@jakobsternberg1807 V8 engine uses JIT compilation for hot code (code that runs frequently).

[@anissbenthami]

Can you please do a programming terminology explanation video because I miss most of the information because of it and I find a lot of confusing and completely different definitions online

[@ebin2222]

Set.has has some optimizations (most likely completely eliminated) tied to it, if you do nothing with the result it it's like 80 times faster than if you do something. In your example, just having an accumulator n and doing n += +testSet.has(value) (and doing the equivalent in the other test), will significantly reduce the difference between the two. This is especially noticeable if you add a bench test where you do literally nothing (an empty body/semicolon), it has the exact same perf as the set one.

[@ucmRich]

*** How can we put JavaScript (or the whole deno) in a cpp program for use as a scripting language for programming game logic in a 3D game engine? DXStudio used JavaScript as it's scripting language and I want to put that into another game engine or just make my own game engine with JS. Can Deno be used for this?

[@darkenlightmage]

If you include and link the node or deno (or just the V8) runtime with the project, you can directly invoke the interpreter inside whatever application you want. It is then a matter of passing the right values to the interpreter environment so that you can modify external values using JS.

[@ucmRich]

@@darkenlightmage omg i would love that! i have been wanting to build a FOSS game engine inspired by my experience with DXStudio. ^_^ i hope can get it right

[@marcmcintosh6715]

can you add to the suite? ``` function sum(arr: number[], count = 0) { if (arr.length === 0) return count; const [head, ...tail] = arr; return sum(tail, count + head) } ```

[@QuentinBzt]

Bro is sold to the DENO cause, we wanna see Bun content as well 😛

[@collinthomas6288]

Having built in easy to use bench marking is really what makes fast code. Make benchmarking and debugging common place .

[@codernerd7076]

Deno course!!!

[@whyneet]

In databases, the index lookup performance is not O(1), but O(log n) assuming the index uses a B-Tree

[@pixiedev]

Right, but he is not talking about database. it's for Set which uses hashing and is O(1) in almost every time.

[@Exilum]

Sets are almost always O(1), and the worst case isn't even that bad.

[@dave6012]

@@pixiedevhe compared the O(1) lookup of a Set to a database index, which as @whyneet pointed out, is not O(1).

[@inwerpsel]

Notably missing here is doing a performance recording on a real world app. That will allow you to see where the bottleneck is. You won't get that information by running some arbitrary small component of your app an unrealistic amount of times in a benchmark. It's beyond me how this is not standard advice when it comes to JS performance. You literally just press F12, find "Performance" tab, hit record, do any sequence of interactions, and just observe where it's spending time. This will point you right to the function calls that are your bottleneck.

[@AvanaVana]

Why didn’t you include the array to set conversion in the benchmark for set?

[@Daniel15au]

Because it's part of setting up the test data, which is usually excluded from benchmarks. You wouldn't create a new set every time you want to search for something, so it doesn't make sense to include it in the benchmark.

[@kacaii3349]

More videos about Deno please!!

[@Joel-co3xl]

The set example is misleading. Remember, the act of creating a set is always more expensive than linearly searching through an array for a value. It’s only worth it if you are going to do multiple look ups on the same set.

[@Daniel15au]

You don't create a new set every time you want to search it though. You create the set once and use it throughout your code. Benchmarks generally exclude setup code (including creating test data)

[@WiseWeeabo]

let a = new Array(42); if (Object.seal) { a.fill(undefined); Object.seal(a); } Use fixed length arrays if you want to be fast.

[@trappedcat3615]

It matters if the array is large... or if the number runs on that small array is large

[@MaulikParmar210]

Irony is people want performance from high level language like JS for which multiple runtime exists, each trying to impmement same stuff very differently from each other. If you really need it, than you won't be using JS or Go or even rust and rely C for close to metal performance. It also has own abstractions so it really drills down to a Software Engineers ability to understand machine at it's core level. Unfortunately alot of devs are not computer engineers or taught formally about computer architecture so squeezing out performance would be done by someone who excels in both relms and most of the world won't even need that kind of optimizations either. Thus compering benchmarks is pretty amature, at the end of the day solution and it's worthiness totally depends in usecase specific implementation. These type of comparison is inevitable because of lack of education on topics thst really matters after some point. And no if you're writing your app in JS for loading millions of records, that's not going to give you performance that a bare metal code will provide. Choose your tools wisely.

[@funkmedaddy]

In a perfect world you get to choose your tools, but we do not live in a perfect world and sometimes you're just given the tools and have to work with them. While it's worth pointing out that JS should not be your language of choice for performance oriented tasks, it doesn't mean you can't try and make the best of what you have

[@sidekick3rida]

what was the cost of converting the array to a set?

[@dave7244]

The traditional for loop btw that you wrote isn't that optimised. If you cache the length of the array as a variable it doesn't need to pre-calculate it. There are even crazier optimisations with while loops you can do.

[@narrei666]

does set also work this well for array of objects?

[@ence7846]

no

[@Mr-Raptor]

stringified objects

[@devbisht6780]

you soab .. i found this channel rn.. dk how much I missed on..

[@danser_theplayer01]

I have one easy tip for performance. All array methods suck arse, and are hard to read, just write a for loop. This is the best answer every time all time. There is no question. If you do more than one thing then you'll chain methods without realising that you're looping more than once. Even if you don't chain, you still need to run a callback on methods. The for in/of loops are generators. Therefore the fastest is ALWAYS a regular for loop. I only write for loops because I don't know for sure that the array or object will be small enough, and also for loops are extremely versatile (doing what you usually do with 3 loop methods, in one loop), and readable.

[@oleg4966]

Eh, I'm quite fond of filter and sort methods. They're a PITA to translate to a pure for loop, and the resulting code is hard to read.

[@samuelebernardi1162]

Wouldn't the time to copy the array items to a set be longer than the actual research?

[@nicsilver12]

Are you ok man? You sound a little down compared to your usual. Either way awesome video!

[@IngwiePhoenix_nb]

So, how many "nodejs-bench" packages do exist by now?

[@jimbobu]

JavaScript developers when iterating over an array is slower than a single equality comparison: 🤯

[@TheOriginalJohnDoe]

Bless Deno for making this a built-in feature. Such an underestimated aspect for developers!

[@jsleaddev]

Would these results be different in Node?

[@thyran6288]

Of course using a set or a map to lookup values in O(1) time is always faster, but you would need to use these from the start. If you create those based on an array every time just because you think it is better, you waste all the time before the lookup so in the end it does not make a difference. It just depends on the data at hand. If your implementation does not require an array don't use one, and if it does a Set will probably not help you anyway

[@varuns3763]

Think of how hashing is done behind the scenes, not optimal for small dataset

[@nocturne6320]

5:40 ... don't tell me JS "devs" don't know about how lists, sets and dicts should be used...

[@valentinrafael9201]

If you unroll the loop it will turn out to be way faster. It depends on the size of the iteration count.

[@sugaith]

these Rob Pike rules are perfect

[@krowhenkvothe]

Like for the DENO course

[@npc-drew]

like because this account is a bot.

[@dgdev69]

In my workplace when juniors commit loop other than for loop i guess they have used gpt. Best part is PR gets merged without comments.

[@TheOriginalJohnDoe]

brb rewriting all my for-loops in our codebase to traditional for-loops

[@82TheKnocKY]

These examples don't consider the fact that JavaScript is a JITed language. These microbenchmarks are never accurate to how little/much this function would actually get optimized if it was in a real application

[@LiveType]

Not even. Micro benchmarks aren't super indicative of actual real world run times unless it's something hilariously trivial. Measure the entire application performance then make decisions if it's too slow. From my own experience, the fewer heap allocations the better. Like I'll take slower algorithms that perform significantly fewer heap allocations. Managing the GC pileups from languages becomes significant and results in massive performance penalties when you approach saturation limits. I find that matters more in real world production workloads in the long run.

[@sugarsama7716]

It's kinda misleading... I run a bench with the same quicksort implementation, and it was about 97% slower than Array.prototype.sort,

[@edwarda7096]

Will you update nextjs course to next15?

[@jurasiks]

You should run benchmarks on different machines. Maybe 100-150 to get some stats

[@FirroLP]

If you can still change the video in your course: Not including the creation in the benchmark is a big flaw because creating a set is slower than an array. Obviously doesn't make such a difference, but it's a mistake and worth talking about

[@zeikjt]

I think y'all are thinking that you'd still have an Array, but why? Just use the Set the whole time, no need for the original Array.

[@gulllars4620]

The set lookup comparison to array contains isn't fully fair though. There should also be a benchmark version comparing the set creation + N lookups to just running the foreach array search. In most cases though, unless that whole context is in a loop or inner loop (in which case, dafuq?) the cost of making the hash set when N is small won't be noticeable as a part of the user experience, so guarding against a horrible bad perf case if there is scale comes at a low absolute cost when it isn't.

[@jordymaryns4945]

I hope there will be a lifetime purchase option in the future as well.

[@Roboprogs]

Thanks? I’ve been programming for 40 years, and these days I generally don’t worry about performance in the browser or Node, other than code and data size. The sort and search stuff pretty much all happens in the database. So I have to make all the execution time measurements against THAT, and avoid crippling it with stupid crap like ORM. So, yeah, same process, but not the place I run it. Batch C code on files in the 90s. Again, same process.

[@RustIsWinning]

Deno is so winning!! B word could never 😂

[@brogotbonkers]

that's an ad? I've tried to create a blog with Deno but it really sucked. not even close to what Ryan promised on demos lol