Look up performance question

>"don't use for loop user use map and forEach, compiler will optimize it anyways!"
>it's actually slow as shit

Just chose a compiled language off the top of my head. Choose any language you want, really. I guarantee you the compiler will outperform you 99.99999% of the time in optimization.

Any proof on that one? Pic related, all the different ways of iterating over a loop in Java (assumed that's what you're talking about since `forEach` is a thing in JS or Java). All are essentially even when considering error.

Attached: Screen Shot 2018-03-29 at 1.18.15 AM.png (671x225, 88K)

I was referring to js.

the compiler can’t optimize performance for memory usage and system calls so it can’t do everything

Well, you at least proved you know absolutely nothing about the topic at hand. That's a start, I guess.

I've been talking about beating the compiler. JavaScript is not a compiled language; it's interpreted and while V8 and some other JS engines attempt optimization, it's nowhere near the levels of a proper compiler such as LLVM.

>V8 compiles JavaScript directly to native machine code before executing it

There is hope, user. Demoscene exists. Assembly language will never die as long as machine code exists. Fast inverse root will exist as long as complex functions take more than 1 cycle to complete (end of Moore's law?). L2 cache will exist as long as RAM is slower than the CPU.
The hacks will always remain in the realm of the low-level and the foundations of computing. A better question is, who will become the next great hacker?

JS is almost always JIT-ed nowadays. It's compiled when it can be, and is recompiled as needed. The compilers optimize the shit out of everything they can. There's a ton of seemingly innocent things you can do that will cause the compiler to bail out of the optimization, murdering the performance of your code.

Understanding what the compiler is doing will help you code in a way that the compiler can optimize efficiently. That goes for any language. Anyone who thinks a compiler can optimize any stupid code into something fast doesn't know what they're doing.

Just get your application out and working before worrying about the nitty gritty

You can use compilers to optimize memory performance as well. Take a look at Polly for LLVM.

>have problem with x in my code
>go to stack overflow
>find question that's exactly the same issue of me
>closed for being duplicate of y
>go to y
>try the solution
>doesn't work and isn't as specific to me as the other one was
wonderful

user, when people who are finding bugs in compilers tell you things, you should listen.
You shouldn't think about optimization when you can't even develop for shit. Make a working thing first - then you may optimize if it's necessary.

How many nanoseconds did you save by replacing "forEach" with "for", user? Stop being a fucking retard who has no idea what he's talking about.

Why would you assume randoms on stack overflow are finding compiler bugs?
Why would you assume I can't develop for shit?

forEach vs for is significant performance wise, sorry you're too retarded to handle writing maintainable and performant code.

Your question may be valid, but generally when I see people bring up "which is faster" question they are on the completely wrong track. Noticeable performance increases almost exclusively happen to improvements in your algorithms and architecture. Being able to optimize a handful of instructions out of your if statements is not going to have a meaningful impact on your program. Unless you are actually working on a very hard limited system, there is zero reason to worry about performance until you have a working product.

If this is just a hobby, and you are a perfectionist, you can ignore this advice. Career wise, no company wants the employee who spends hours trying to write perfect software - he is just as bad as the programmer who consistently submits broken PRs and broken code. You want that middle ground. Write good, not perfect software, which you can ship at a steady pace.

I love the people on here who have never released or even helped to release any sort of product but sperg out about optimization in their little hello world script.
>look guys, it only takes 100 nanoseconds instead of 101
>Oh you developed a whole service with web frontend, database backend and a lot of features? Have you seen my optimized sorting loop? I can call it from the command line, it sorts only numbers and nobody uses it but the loops are optimized. Did I mention that the loops are optimized?

Attached: dunce4.png (645x729, 105K)

I'm working on code for popular website, it needs to be performant.

Myaano is so cute

Attached: tumblr_o6n5mc8YRo1tydz8to1_400.gif (346x429, 355K)

Because randoms on stack overflow DO find compiler bugs and then the same people say "stop over-optimizing shit"
Because it's always inexperienced faggots who think they should prioritize optimization over finishing the project.
You did not understand the question. The difference is significant in relation to each other - but how much of the actual time do you save? Even if we take a relatively slow language like JavaScript running in a browser where forEach is about two times slower than an optimized for loop - your "significant performance difference" - we are still looking at values less than a millisecond saved, unless you're running loops for millions of iterations - then you might save a quarter of a second. Once. Chances are, however, your "optimization" should start by asking yourself "why the fuck am I running hugeass loops? Maybe I should fix my shitty logic?"
In faster languages - even in dedicated OOP ones like C#, using for over forEach will save you literal nanoseconds, sometimes even less.

And even if you're a literal god of shitty JS scripting, you won't be able to write a more readable and maintainable code by using "for" instead of "forEach" because the whole point of latter is primarily readability and maintainability. Meanwhile, your way of thinking makes you no better than webmonkey hipsters who use "map" instead of "for" because it's "less typing".

Another good example would be jQuery (or, honestly, any fucking JS library out there) - it's way slower than the vanilla JS, but it's much more intuitive to write on and to read (debatable). Hence it is popular.

Of course, everything changes if you're writing a real-time program for which performance is critical. However, chances are, when you'll start writing not utterly shit real-time programs, you'll know enough about the priority of the optimization to stop being a delusional NEET hipster.

>Another good example would be jQuery (or, honestly, any fucking JS library out there) - it's way slower than the vanilla JS, but it's much more intuitive to write on and to read (debatable). Hence it is popular.
There's a reason Lodash took over from Underscore, jQuery, etc...
If you can't understand a simple for loop you're a shit programmer.

Attached: Screen Shot 2018-03-28 at 11.49.11 PM.png (1434x1450, 357K)

>If you can't understand a simple for loop you're a shit programmer.
If you can't understand advantages of forEach over "a simple for loop" - you aren't a programmer to begin with, user.

>"the compiler will optimize it"
>actually test it
>it doesn't
>adding an unused variable to a method somehow makes it 30% faster
such is life using C#

Like what? It's significantly slower which is why good libraries like Lodash and virtual dom implementations use plain old for loops.

You have no idea what you're talking about.

uh, that's wrong, sweetie

They're right. People are right when they say compilers are really smart too. Just do whatever you're working on without worrying much about performance. Sure, there are specific scenarios in specific projects where you should worry about performance pretty early on, but 99.9% of the time not really. Then when you have something working see how well it's performing and how much resources it's using. Then find the bottleneck and do your research to fix it.

>Why would you assume randoms on stack overflow are finding compiler bugs?
What do you mean? Every time I've seen a compiler bug getting brought up there clear evidence is provided.

Like readability, you retard. I wasn't joking about hipsters using "map" instead of "for". The main problem here isn't the "performance" - especially for the front-end web development. The problem here is using operation outside of its context.
"Maintainable" code should provide as much information to the reader as possible.
"forEach" has a clear context of "iterate over every single object in the provided collection".
Meanwhile "for" is a loop - that's all. It might be used to iterate over objects, but it might be used for anything else. It might have specific rules of iteration, rather than "every object". If you cache the loop's condition (to increase your performance) it will become unclear - even if you name it properly.
When one debugs some arbitrary code they understand what forEach does by just glancing at it. To understand (not assume) what a for loop does - you have to read it. Not to look at it, but to actually read it, check its conditions, check what it works with. You are a genuine literal fucking retard if you think there are people out there in the industry who "do not understand for loops", it's just one option allows the reader to run their eyes over the code and still understand what it generally does while the other requires them to actually read the code. Meanwhile, the end user is physically incapable of noticing the 50 microseconds performance increase from your "optimization".
When you'll get some experience of debugging actual code, you'll realize that you don't really want to "read" all 10k+ lines of that bullshit, but you still want to know what it does.

figure out your data abstraction properly and writing performing code is trivial.

For loops are easy to understand.
>The main problem here isn't the "performance" - especially for the front-end web development.
JS is used out of front end these days.
>The problem here is using operation outside of its context.
Looping through something is perfectly valid use of a for LOOP.
>it's just one option allows the reader to run their eyes over the code and still understand what it generally does while the other requires them to actually read the code
Wow a whole 5-10 seconds of dev time every once in awhile.
>Meanwhile, the end user is physically incapable of noticing the 50 microseconds performance increase from your "optimization".
Then why do virtual doms use for loops?

>Looping through something is perfectly valid use of a for LOOP.
"iterate through something" method is perfectly valid for Iterating through something.
"Loop one step at time as long as a size of something" is less so.
>JS is used out of front end these days.
How many nanoseconds does it save you when used on the back-end? I'll wait for your reply to this one.
>Wow a whole 5-10 seconds of dev time every once in awhile.
Oh boy, you genuinely think "optimization" boils down to replacing foreaches by fors. Incredible.
Disregarding that, though, those "5-10 seconds of dev time every once in awhile" translate to the whopping 3 microseconds performance increase in 3 seconds long operations! You can pat yourself on the back, user.
>Then why do virtual doms use for loops?
You mean in the code no one is supposed to read? Like Lodash that "only uses for loops" you keep mentioning has an implementation of "forEach" like everything else?
Do you know, by the way, that "for" loop is itself an abstraction for the "do while"? I guess you must use whiles everywhere now, user!
Also, do you know, that approaching zero is faster than incrementing up to a condition? That's right, now you're decrementing an abstract number - fuck that understandable counting "did we reached the collection size yet?" thing!
Maybe you should just write direct jump statements, user? That's how a loop is done in ASM - the fastest of them all! I fucking knew "goto" was the best operator out there - no wonder those jew faggots did not include it in ECMAScript - they don't want to share the goodness! Jews gonna jew, who would've thought...

user, be honest, had you just enroll in a CS school or something?

>"Loop one step at time as long as a size of something" is less so.
No it's been a staple for decades and is completely idiomatic.
>You mean in the code no one is supposed to read? Like Lodash that "only uses for loops" you keep mentioning has an implementation of "forEach" like everything else?
Yeah like my code? If I'm writing high rps node lib that many will use but few will need to read and maintain why should not use a fucking for loop.

>If I'm writing high rps node lib
Then you won't be a retard asking "boy, I wonder, how should I optimize that one particular thing" which you are.
Optimizing a library is a perfectly normal thing to do. After the library is working, that's it.
Preemptive optimization is relatively fine if one is writing something solo but in a team, optimization has a pretty low priority. When everything is finished and properly encapsulated; when the full documentation is done - then you might as well go full turbo-autist on the optimization. That's not the case for literally (literally) every single "stop overoptimizing shit" StackOverflow answer.

>can't respond to y to ask about the more specific version because "please don't necro post".

Attached: cease this faggotry.jpg (2048x1356, 583K)

>ITT: People who can't into math and algorithms so they waste their time being shitty human compliers to feel acomplished and inteligent.
>I-I can't reduce the lookup time from 0(n^2) to 0(log2) and my data structures design is shit, but I memorized how to linked lists in x86 asm

These people are stuck on their "gettin muh work done" treadmill. Instead of not replying when they can't answer a straight question, they want to tell you what question you should have asked.

>what is more efficient here?
>lmao someone knew that once, don't worry about it

Smart person:
>I want to know which is faster, I'll measure it on my target platforms.
Dumb person:
>I want to know which is faster, I'll ask randoms on the Internet.

Attached: 1516313921760.png (645x729, 64K)

Beating a compiler is trivial for anyone with half decent knowledge of assembly.
The easiest and most low hanging fruit is register usage - you are not bound by any calling convention so you're free to use all registers however you want.
It just takes a lot of time.