Update

optimization.md

@@ -59,6 +59,7 @@ These are mainly for [C](c.md), but may be usable in other languages as well.
 - **[Parallelism](parallelism.md) ([multithreading](multithreading.md), [compute shaders](compute_shader.md), ...) can astronomically accelerate many programs**, it is one of the most effective techniques of speeding up programs -- we can simply perform several computations at once and save a lot of time -- but there are a few notes. Firstly not all problems can be parallelized, some problem are sequential in nature, even though most problems can probably be parallelized to some degree. Secondly it is hard to do, opens the door for many new types of bugs, requires hardware support (software simulated parallelism can't work here of course) and introduces [dependencies](dependency.md); in other words it is huge [bloat](bloat.md), we don't recommend parallelization unless a very, very good reason is given. Optional use of [SIMD](simd.md) instructions can be a reasonable midway to going full parallel computation.
 - **Optimizing [data](data.md)**: it's important to remember we can optimize both algorithm AND data, for example in a 3D game we may simplify our 3D models, remove parts of a level that will never be seen etc. Ordering, grouping, aligning, reorganizing the data, changing number formats, adding indices and so on may help us achieve cache friendliness and simpler and/or faster algorithms. For example a color [palette](palette.md) may be constructed so that certain desired operations are faster; this is seen e.g. in [Anarch](anarch.md) where colors are arranged so that darkening/brightening is done just by decrementing/incrementing the color index. In [raycasting](raycasting.md) engines it is common to store images by columns rather than by rows as they will be drawn by columns -- this simple change of how data is ordered increases cache friendliness. And so on.
 - **Specialized hardware (e.g. a [GPU](gpu.md)) astronomically accelerates programs**, but as with the previous point, portablity and simplicity greatly suffers, your program becomes bloated and gains dependencies, always consider using specialized hardware and offer software fallbacks.
+- **Optimization comes at a cost** -- not counting the time and energy put in, optimization will also probably make your source code less readable, more complicated (and so more likely buggy), or maybe even less portable etc. For this you should NOT optimize everything, only optimize where it is worth it -- as said, optimizing non-looped code to run 1 millisecond faster is almost always absolutely useless, it's better to rather have a nicer code.
 - **Smaller code may also be faster** as it allows to fit more instructions into [cache](cache.md).
 - Do not optimize everything and for any cost: optimization often makes the code more cryptic, it may [bloat](bloat.md) it, bring in more bugs etc. Only optimize if it is worth the reward. { from *Game Programming Gurus* -drummyfish }
 - ...