Lead Developer, business owner, US Army veteran. I build things for the web. My website is a bunch of HTML pages that didn't need a framework. Yours can be too!
Please excuse any typos/readability/bad code here... not a fully fleshed-out solution and I haven't run it, just wrote it real-time thinking about how to avoid explicit for loops (but there are 2 implicit loops), and I feel like it will probably be closest to, if not longer than brute force. It's a 'code golf'-ish solution that might look pretty, but actually be very inefficient.
These are the kinds of things I see (and write) a lot for readability on a known-length array, but once we get into potentially large (IE: tens of thousands+) arrays, the impact on the performance isn't well known (or at least analyzed) by the developer in a lot of cases.
Around 50k elements you will see reduce and filter (which are sometimes MORE performant than a hand-written for loop in smaller arrays) start to take longer once the function overhead takes its toll. github.com/dg92/Performance-Analys... is over two years old, and I haven't tested it myself in quite some time, but it matches my experience with it.
I LOVE these types of functions and use them all the time, but it's important to use the right tool from the toolbox.
Thanks for the article. I enjoy a good big-O analysis!
Yeap, for this first set of approaches I purposely stayed away as much as possible from the javascript built in iterators to try and get a baseline raw approach.
I was planning on a second set of tests using more JS native functions. Thanks for the code!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I know it's not as performant as the Map solution, would love to have seen a solution using the built-in array iterators:
Please excuse any typos/readability/bad code here... not a fully fleshed-out solution and I haven't run it, just wrote it real-time thinking about how to avoid explicit for loops (but there are 2 implicit loops), and I feel like it will probably be closest to, if not longer than brute force. It's a 'code golf'-ish solution that might look pretty, but actually be very inefficient.
These are the kinds of things I see (and write) a lot for readability on a known-length array, but once we get into potentially large (IE: tens of thousands+) arrays, the impact on the performance isn't well known (or at least analyzed) by the developer in a lot of cases.
Around 50k elements you will see reduce and filter (which are sometimes MORE performant than a hand-written for loop in smaller arrays) start to take longer once the function overhead takes its toll. github.com/dg92/Performance-Analys... is over two years old, and I haven't tested it myself in quite some time, but it matches my experience with it.
I LOVE these types of functions and use them all the time, but it's important to use the right tool from the toolbox.
Thanks for the article. I enjoy a good big-O analysis!
Yeap, for this first set of approaches I purposely stayed away as much as possible from the javascript built in iterators to try and get a baseline raw approach.
I was planning on a second set of tests using more JS native functions. Thanks for the code!