Update
This commit is contained in:
parent
85660ae82e
commit
22af8b4635
12 changed files with 57 additions and 11 deletions
|
@ -30,6 +30,7 @@ These are mainly for [C](c.md), but may be usable in other languages as well.
|
|||
- Search literature for **algorithms with better [complexity class](complexity_class.md)** (sorts are a nice example).
|
||||
- For the sake of embedded platforms **avoid [floating point](floating_point.md)** as that is often painfully slowly emulated in software. Use [fixed point](fixed_point.md).
|
||||
- **Early branching can create a speed up** (instead of branching inside the loop create two versions of the loop and branch in front of them). This is a kind of space-time tradeoff.
|
||||
- **Reuse variable to save space**. A warning about this one: readability may suffer, mainstreamers will tell you you're going against "good practice", and some compilers may do this automatically anyway. Be sure to at least make this clear in your comments. Anyway, on a lower level and/or with dumber compilers you can just reuse variables that you used for something else rather than creating a new variable that takes additional RAM; the only prerequisite for "merging" variables is that the variables aren't used at the same time.
|
||||
- **You can optimize critical parts of code in [assembly](assembly.md)**, i.e. manually write the assembly code that takes most of the running time of the program, with as few and as inexpensive instructions as possible (but beware, popular compilers are very smart and it's often hard to beat them). But note that such code loses portability! So ALWAYS have a C (or whatever language you are using) [fallback](fallback.md) code for other platforms, use [ifdefs](ifdef.md) to switch to the fallback version on platforms running on different assembly languages.
|
||||
|
||||
## When To Actually Optimize?
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue