Web devs

...

Most of the time it's better to use something other than a for loop in js because any efficiency gains would be miniscule.

Are you motherfuckers seriously trying to talk about efficiency in a language where every single number is a float? Come on, just use it's own inbulit iterator or whatever crap the ES shat out this year.

Also, a map function and a loop serve two completely different purposes, even though their functionalities often overlap.

Webdevs are cancer
they would rather use map and a lambda than foreach

That's exactly the point I was making.

>where every single number is a float?

in specification only. that doesn't mean the compiler can't reorder or recognize mostly integer math and store variable data in mostly integer ways.

also javascript now has an integer type in the upcoming ESNEXT spec and it's already in chrome. new BigInt()

would rather use an iterator than a for loop in 2018 anyhow. forEach just happens to be a proto that works kind of like the for of or the grosser for in.

plus the benchmarks on this are pretty meh. maybe 10-15% greater throughput with standard c style for loop, but really, if you're working on such a massive dataset, then you'd profile and optimize accordingly.

for loops are massively faster, up to 60% in some environments

adding functional overhead everywhere is a mark of a bad programmer

OP is an imperative pleb.

>󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦󠇦 (You)
that's not my name

This is the fucking state of Jow Forums in 2018. 10% efficiency gain for literally no effort is amazing. Large companies search for fucking 2% gains. Even I know this as a first year CS student.

>a mark of a bad programmer
No, a bad programmer is someone who prematurely optimizes their code and opts for the less concise route because of 'muh performance' they saw in an irrelevant microbenchmark. In nearly every real world scenario that exists, the body of your loop will have a far greater cost than the looping construct itself. Remember, the limit of x/(x+1) as x grows. Unless your app is spending 90+% of it's time running loops that do very little, in which case your app doesn't accomplish much, a for loop is just more code to accomplish the same thing.

Dude. A for loop is no effort and it's more efficient, you should use it if you aren't a pajeet

naa i see people putting function calls in the second arg constantly
it's super common in JS for programmers to write out str.length in that position rather than initialise it into 'x' beforehand and just use that.

#!/usr/bin/nodejs

var N = 10000000;
var arr = Array.from({length: N});

var before = Date.now();
for (var i = 0; i < arr.length; ++i)
{
arr[i] = i;
}
var after = Date.now();

console.log(after - before);

before = Date.now();
arr.map((_, i) => i);
after = Date.now();

console.log(after - before);

Attached: Screenshot_2018-05-04_14-29-16.png (736x465, 159K)

Don't reply to bait. He even used reddit spacing to get more guillible faggots like you.

>first year CS student
Color me surprised. Even a 10% improvement in the looping itself will be dwarfed by the cost of the work being done inside of the loop, as well as all of the other things your app could be doing. Make an Ajax call? Your loop optimization becomes worthless. Trigger a page reflow? Your loop optimization becomes worthless. Log a message in your logger? Your loop optimization becomes worthless. JSON.parse? Your loop optimization becomes worthless.

You will get a 10% performance gain if your app is literally nothing but looping over objects and not doing anything with each object as you loop over it. In real world situations, this optimization is the equivalent of worrying about reducing string concatenation or boxed primitives when your app spends most of it's time waiting on disk or SQL queries.

Do something more computationally expensive than arr[i] = i inside your loop and then pull up the benchmarks. Real programs do more than just array assignment.

This is the problem with microbenchmarks. You need to compare the entire application running end to end in order to see if there will be a performance improvement, since that's what the customer is going to do.

How expensive a square root is for you?
╡$│./stuff.js
737
6503
╡$│cat stuff.js
#!/usr/bin/node

var N = 10000000;
var arr = Array.from({length: N});

var before = Date.now();
for (var i = 0; i < arr.length; ++i)
{
arr[i] = i*Math.sqrt(i);
}
var after = Date.now();

console.log(after - before);

before = Date.now();
arr.map((_, i) => i*Math.sqrt(i));
after = Date.now();

console.log(after - before);

The whole point was to compare the overhead of the looping method itself.

It is not premature optimization to follow best practices.
I agree that with javascript, you often need to codegolf your code because "fast" includes transfer speed as well and nothing important is done in JS anyway.
The mentally lazy programmer in the OP was optimizing for server speed (poorly I might add) at the cost of the users processing power.

Isn't js nowadays heavily optimized though? I doubt it will make any difference at all. In proper languages you can use inline functions to achieve the same thing too.

>I agree that with javascript, you often need to codegolf your code because "fast" includes transfer speed as well
Now you're just being ignorant, though. There are plenty of tools that compresses your code by removing whitespace and renaming variables, etc. There is no need to write deliberately obfuscated code in order to "save space", when a compiler can do a 10x better job than you.

>Isn't js nowadays heavily optimized though?
See >In proper languages you can use inline functions to achieve the same thing too.
We're talking about JavaScript though.

Better than array assignment, but still incredibly trivial.

If your program only spends .5% of it's execution time doing x, optimizing x can only make your program at most .5% faster, and that's if you optimize x by an order of magnitude. Find me a real application where any significant portion of the workload is the actual iteration over the collection. Optimizing anything other than the dominant consumer is pajeet tier thinking.

Also, FYI benchmarking on a cold vm is also pajeet tier

Which is irrelevant in real world applications because it won't make them faster

First of all, the point is to measure the overhead in looping with map rather than a for loop, not to benchmark any other job.

Secondly, see pic related.
It is clear that map does not actually scale, as the performance overhead is not constant.

Attached: Screenshot_2018-05-04_15-01-50.png (430x1075, 198K)

See It is relevant, because the overhead of map clearly doesn't scale.

Using map in place for forEach is plain retarded. Though I expect comparable performance drop with forEach.

>Using map in place for forEach is plain retarded.
I agree.

>Though I expect comparable performance drop with forEach.
There is, you can run the code in with forEach() instead. It's not as bad as map(), but it is still considerably worse than just a simple for loop.

If it doesn't impact the actual application's performance, it doesn't matter. I am not advocating for using map instead of forEach, since that is literally retarded. I am however stating that worrying about the performance overhead of forEach is pajeet tier thinking.

A while back I was on a scope call for some infrastructure upgrades. The sales engineer wanted us to buy the 10x more expensive product because it did hardware TLS, and that the hardware TLS is 100x faster than software TLS. I told him to fuck off, because it wasn't going to make our apps 100x faster. It wasn't even going to make them 1% faster, because our apps don't even spend 1% of their time waiting on TLS termination. By the logic of this thread, though, I should have bought all of that shit like a retarded. 7 figures for 'muh performance'

These are all trash DESU. It's the black pill of web dev: "this shit all sucks and I've given up". Looks like Unix plebs trying to enter the 21st century though so that's nice. Go find vanillajs Jesus and some AspNetCore and don't look back.

>If it doesn't impact the actual application's performance, it doesn't matter. I am not advocating for using map instead of forEach, since that is literally retarded. I am however stating that worrying about the performance overhead of forEach is pajeet tier thinking.

Except it doesn't add a CONSTANT overhead, it adds an overhead that doesn't scale.

Attached: Screenshot_2018-05-04_15-27-31.png (518x576, 238K)

>inb4 why don't you just pass doJob directly to forEach

Attached: Screenshot_2018-05-04_15-30-22.png (547x600, 267K)

Go get a real web application, replace all for loops with forEach loops, and benchmark that. Your benchmarks are only representative of apps that do literally nothing. Nobody is getting paid to write node js scripts that fill an array with numbers.

You don't seem to be getting this. Unless the app is spending virtually all of it's time doing nothing else but running the forEach iteration code, it's not the dominant consumer and the performance difference is totally irrelevant. This is why microbenchmarks are not used in performance tuning. Every web application I've ever been paid to speed up was slow because of inefficient DOM manipulation, or inefficient retrieval of data. It's never because someone used forEach, because the overhead of iteration is trivial compared to the program doing stuff. It's piss in the ocean.

You’re still not getting the fucking point. Using forEach increases runtime regardless of the job being done, as clearly demonstrated by the five different examples being posted.

This shit is a problem because junior devs read it and think, "Ah, so that's how I do that in JS," without fully understanding what the code is doing.

I had an applicant try to pull this during an interview. Even more embarrassing was that using the return value of map would have simplified his code greatly.
var outputArray = [];
inputArray.map(function(item) {
// do stuff
outputArray.push(newItem);
});

I asked him about why use map for that, and it turned out he didn't even know that map returned anything.

Performance is honestly irrelevant for this. It's about education and misleading coding styles.

He is right though, for all the wrong reasons.

You shouldn't use for loops, or forEach.

Anything you can do with them you can do with maps and folds, if you think you can't you just don't understand what you are doing.

It's a meaningless gain though, because it will not even show up in your monitoring. You'll open Google analytics and your page speed will be identical. You'll run load tests and see no difference. Performance gains that are smaller than the margin of error are not even worth talking about, let alone implementing.

Jesus fucking christ, you really need to fuck off back to r/java, you moronic, inbred nigger. "It doesn't matter if the client's CPU runs at 100%, the application works!!"

Aesthetic > Simplicity

Attached: 1524369653463.png (1280x1092, 598K)

>starts twerking

That's literally how the industry works because it allows hardware manufacturers to keep on selling the same shit every year.

uwu

The CPU doesn't run at 100%, it runs at 1% because 99.999999999999% of web applications spend all of their time waiting for user input or waiting for AJAX calls, and when they're not doing that, they're reflowing the page or rerendering. 0% of the CPU time is spent handling array iteration, so trying to speed that up is pajeet tier shit.

No, user. You are the pajeet for deliberately making shit worse for everyone.

What you posted is completely in agreence with the post your replying to retard

>no u
Great argument. Trying to microoptimize logic in asynchronous contexts is why you LARPing fags will never get anything done in the real world.

>worrying about the performance
>pajeet

I don't think so.

Using more resources when they are not required is literal pajeet-tier fuckery that leads to bloat and sluggishness. Fuck off back to r/java, pajeet.

I hope you're implementing everything you write in assembler, you wouldn't want to risk wasting those precious CPU cycles, right autism-kun?

>Comparing using map in place of a for loop to using C instead of assembly
Fuck off back to whatever normie hellhole you came from, pajeet. Your kind is not wanted here. Lurk more before posting.

forEach is javascript iterates over the indicies, so it's the same as a for loop

>2018
>Not building your own iterator class for max efficiency

Attached: c2f.png (667x670, 648K)

wow

Really, only knowing one language produces the shittiest devs.

It doesn't. You can abuse Array.prototype.map to get the same functionality of Array.prototype.forEach but it's bad and should never pass a code review. The fact Array.prototype.forEach is part of EMCAScript is an abomination.

The bad thing here is this developer isn't mapping anything. He's most likely doing some imperative logic inside an Array.prototype.map.

>normie
>pajeet
>Lurk more
try fitting in harder

Attached: BZeDeq1IUAAZ2Lk.jpg (599x428, 16K)

I don't get why the engines won't optimize the call, e.g. make them same performance. Surely we have come far enough with ES8 for that, no?

>let's not optimize our code where we can because it won't matter anyway
this pajeet-tier way of thinking is exactly why web development is a retarded clusterfuck

lets cherry-pick this one guys stupid fucking opinion and generalize it to all web developers

>BCHS
lmao, try making a serious web application with that stack
you wanna know how I can tell you've never done real web development?

I'd guess it's because forEach allows you to specify "this", meaning that unlike the for loop we do genuinely need to consider the given context, while the for loop only needs the context of the single enclosing function.
However, with ES6 arrow functions, since this is inherited from lexical scope, I don't see why that can't be optimized.
The takeaway is JS is shit.

can we stop having this thread on the daily