I didn’t look at the first link, the second Efficient C link for ARM is very good, thanks for searching and sharing, I’m going to direct people to this link.
Just like the Zen of Assembly language is still relevant today, as when it was released, not because modern x86 is associated with 8088/86 and the “eaters of the cycle,” but because the thought process and analysis taught, over time, is changing. Cyclic eaters can range from language to language or target, but how do you find them. This book was outdated and irrelevant when it went for tuning for 8088/86 or so, somewhere I read somewhere, but I read it and used what I learned every day since then.
Here, the effective C for ARM is well applicable to similar elements in C ++, but, more importantly, look at the early slides until any specific structures or code are shown. You have to analyze, checking and using the profiler (no different from what the Zen of Assembly language says, look at it and time). Then the Efficient C page for ARM continues to check some examples, takes your C ++ code and compiles it, and then parses and sees what is actually happening. The problem with this is that you should understand that there are many tuning controls in the compiler, and compilers are constantly evolving, and different compilers say that gcc, llvm (clang) and visual C / C ++ are completely different. The same C ++ source code presented to different compilers and different versions of compilers and to the same compilers with different optimization settings will give different results.
When you want to perform micro-optimization, you need to learn a lot about how compilers work, gaining a considerable amount of experience in disassembling and analyzing what the compiler does with your code (FOR EVERY TARGET YOUR CARE). Only then can you begin to make real optimization without resorting to writing assembler. Despite the fact that people can tell you that you can do this, you can significantly improve performance in some situations by simply redoing structures, functions, lines of code, etc. Also make code that is more portable for other processors and will make code that is usually faster on multiple platforms, not just one. Nay-sayers are right in that you need to have a good reason for this, sometimes it does not change readability, but often it makes it far from making your code unreadable or unbearable or fragile, etc. Always organize your structures in a reasonable way, larger, aligned variables first, and then gradually smaller. Other things, although you may not want to do this as a habit, but only for special occasions.