4 ms·
>And a good compiler doesn't only optimize for speed. It also optimizes for code size, memory usage. No they don't. Code size is rarely a problem (embedded pr
by 0x07c0 11y ago
>And a good compiler doesn't only optimize for speed. It also optimizes for code size, memory usage.
No they don't. Code size is rarely a problem (embedded probably cares..). Optimizations will in most cases lead to larger code, loop unrolling, inline expansion etc.
In c the compiler cant't, in most cases do anything about memory usage. (Probably could pack structs.. , but that is not something the compiler would do I think, you would break ABI with non optimized code). In managed languages, memory usages is probably more depended on the runtime system GC, then compilers.
GCC has a flag for code size optimization -Os
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
- dkopi 11y agoFrom that exact link: "Turning on optimization flags makes the compiler attempt to improve the performance and/or code size at the expense of compilation time and possibly the ability to debug the program." "With -O, the compiler tries to reduce code size and execution time" So actually yes, The compiler optimizes for both size AND speed. Sometimes you can optimize for maximum speed (-O3), and sometimes optimize for minimum code size (-Os). You can even optimize for best debugging or best compilation times, and forget about size/speed. As for memory usage - 1. First of all - code uses up memory. smaller programs = less memory used for holding the exectuable code. 2. Consider the various ways you could compile a switch(-case) statement. You could build it as a set of conditional branches one after the other, you could compile it into a binary tree search (or a hash dictionary lookup), and you could jump to an address found in a lookup array table. This former method is also called a "branch table". https://en.wikipedia.org/wiki/Branch_table https://en.wikipedia.org/wiki/Branch_table A branch table would be the fastest method for implementing a switch with a few sequential values (0,1,2,3,4,5) But would be a really bad idea for sparse values (0,200,5000,10000,200000). Choosing not to use a branch table for sparse values is an optimization for Memory usage. And compilers make this decision all the time.