No.
Compilers optimize code as-written. If your code is stupid and slow due to logic the compiler isn't going to help. If you decided to busy wait instead of using callbacks or whatever, the compiler won't fix that. If you use 64 bit data-types and waste 4x the RAM and you're using a lot of them, the compiler won't optimize that.
I take the attitude that clear code is preferable to less clear, hand optimized code. If you aren't getting sufficient performance, benchmark the code to find trouble spots and optimize those.
Another thing that hasn't been mentioned yet is that performance profiles have changed massively over time. In the old days, computers were slow and every instruction counted, so it was worth microoptimizing every little thing. Nowadays, computers are much faster but process larger amounts of data; as a result, most of the time is spent in that very small code section that goes over your large input. If the thing you're optimizing makes up 10% of the total runtime, the most you can achieve is an 11% speedup. I recently worked on something that spent 80% and 18% of its time on two functions respectively, so there was no reason to optimize anything unrelated to these two. If you don't measure what tiny part of your code is actually performance-critical, chances are that you will waste your time, both optimizing it and dealing with the less readable optimized version later.
I was looking at a program that processes some data and displays it. I wanted to make it use a different data source where it would use 4x the amount of data, I figured maybe 4x slower, shouldn't be too bad. Made the changes... it was SLLLOOOOOWWWWWWWWWW.
for i in data_to_display[]:
for j in data_to_display[]:
for k in data_to_display[]:
The extra computing time is neccessary for doing the needful.
Understanding the theory behind MVC is a good idea, but the higher level idea of splitting your code into different concerns is even more important, and essential to becoming a good programmer. However, React doesn't follow the MVC pattern (without you forcing it to), so it won't help you code React directly.
Sadly I may have filed a bug report so it would dox me.
You don't even need a profiler, even a couple of print statements for elapsed time in suspected hot spots will do in a pinch. Still good to do function level profiling, because it's less work overall and can also catch hidden performance errors.
Algorithmic complexity and cache-friendliness are two things that are all but lost on modern pajeet devs.
This is one of those things that compilers can't fix. Yes, the compiler stops you from having to worry about the instruction pipeline or which way your for loops go (down is slightly faster on common architectures for executing a block of code n times), but it can't stop absolute retards from using linked lists for matrices and slowing things down by several orders of magnitude because of all the dereferences.
Please tell me they were doubly linked across and down
Please tell me they were doubly linked across and down
Did they have any diagonal links for faster transpose operations, as well?
If it was sorted data I would hope they also dispersed some skip links throughout as well, for faster searches.
Obviously the correct solution is to link each element to every element, including itself. Can't have a good matrix implementation without being able to index every value! Man, if only there was a way to compactly store a rectangular array of numbers... I know! Let's store all our links in a linked list!
I believe this is called the "Alabama Tree" where there are always loops in the family tree and everyone is related.
I get the sense this is the sort of thing the root of the problem is. Mastering time complexity is rapidly becoming a lost art; the compiler can't save you if you're just a retard with a basic grasp of loops. Some of my buddies were complaining recently about the slow dogshit their students today write compared to just a few years ago. Beginner programmers never test their things at scale.
