事情應該盡可能簡化，而不只是簡單一點點，一愛因斯坦
雖然使軟件正確的工作好像應該是一個工程合乎邏輯的最后一個步驟，但是在嵌入式的系統的開發中，情況并不總是這樣的。出于對低價系列產品的需要，硬件的設計者需要提供剛好足夠的存儲器和完成工作的處理能力。當然，在工程的軟件開發階段，使程序正確的工作是很重要的。為此，通常需要一個或者更多的開發電路板，有的有附加的存貯器，有的有更快的處理器，有的兩者都有。這些電路板就是用來使軟件正確工作的。而工程的最后階段則變成了對代碼進行優化。最后一步的目標是使得工作程序在一個廉價的硬件平臺上運行。
提高代碼的效率
所有現代的 C 和C++編譯器都提供了一定程度上的代碼優化。然而，大部分由編譯器執行的優化技術僅涉及執行速度和代碼大小的一個平衡。你的程序能夠變得更快或者更小，但是不可能又變快又變小。事實上，在其中一個方面的提高就會對另一方面產生負面的影響。哪一方面的提高對于程序更加的重要是由程序員來決定。知道這一點后，無論什么時候遇到速度與大小的矛盾，編譯器的優化階段就會作出合適的選擇。
因為你不可能讓編譯器為你同時做兩種類型的優化，我建議你讓它盡其所能的減少程序的大小。執行的速度通常只對于某些有時間限制或者是頻繁執行的代碼段是重要的。而且你可以通過手工的辦法做很多事以提高這些代碼段的效率。然而，手工改變代碼大小是一件很難的事情，而且編譯器處于一個更有利的位置，使得它可以在你所有的軟件模塊之間進行這種改變。
直到你的程序工作起來，你可能已經知道或者是非常的清楚，哪一個子程序或者模塊對于整體代碼效率是最關鍵的。中斷服務例程、高優先級的任務、有實時限制的計算、計算密集型或者頻繁調用的函數都是候選對象。有一個叫作profiler 的工具，它包括在一些軟件開發工具組中，這個工具可以用來把你的視線集中到那些程序花費大部分時間(或者很多時間)的例程上去。
一旦你確定了需要更高代碼效率的例程，可以運用下面的一種或者多種技術來減少它們的執行時間。
inline 函數
在 c++中，關鍵字inline 可以被加入到任何函數的聲明。這個關鍵字請求編譯器用函數內部的代碼替換所有對于指出的函數的調用。這樣做刪去了和實際函數調用相關的時間開銷，這種做法在inline 函數頻繁調用并且只包含幾行代碼的時候是最有效的。
inline 函數提供了一個很好的例子，它說明了有時執行的速度和代碼的太小是如何反向關聯的。重復的加入內聯代碼會增加你的程序的大小，增加的大小和函數調用的次數成正比。而且，很明顯，如果函數越大，程序大小增加得越明顯。優化后的程序運行的更快了，但是現在需要更多的ROM。
查詢表
switch 語句是一個普通的編程技術，使用時需要注意。每一個由tb機器語言實現的測試和跳轉僅僅是為了決定下一步要做什么工作，就把寶貴的處理器時間耗盡了。為了提高速度，設法把具體的情況按照它們發生的相對頻率排序。換句話說，把最可能發生的情況放在第一，最不可能的情況放在最后。這樣會減少平均的執行時間，但是在最差情況下根本沒有改善。
如果每一個情況下都有許多的工作要做，那么也許把整個switch 語句用一個指向函數指針的表替換含更加有效。比如，下面的程序段是一個待改善的候選對象：
enum NodeType {NodeA, NodeB, NodeC}
switch(getNodeType())
{
case NodeA:
...
case NodeB:
...
case NodeC:
...
}
為了提高速度，我們要用下面的代碼替換這個switch 語句。這段代碼的第一部分是準備工作：一個函數指針數組的創建。第二部分是用更有效的一行語句替換switch 語句。
int processNodeA(void);
int processNodeB(void);
int processNodeC(void);
/*
* Establishment of a table of pointers to functions.
*/
int (* nodeFunctions[])() = { processNodeA, processNodeB, processNodeC };
...
/*
* The entire switch statement is replaced by the next line.
*/
status = nodeFunctions[getNodeType()]();
手工編寫匯編
一些軟件模塊最好是用匯編語言來寫。這使得程序員有機會把程序盡可能變得有效率。盡管大部分的C/C++編譯器產生的機器代碼比一個一般水平的程序員編寫的機器代碼要好的多，但是對于一個給定的函數，一個好的程序員仍然可能做得比一般水平的編譯器要好。比如，在我職業生涯的早期，我用C 實現了一個數字濾波器，把它作為TI TMS320C30 數字信號處理器的輸出目標。當時我們有的tb編譯器也許是不知道，也許是不能利用一個特殊的指令，該指令準確地執行了我需要的那個數學操作。我用功能相同的內聯匯編指令手工地替換了一段C 語言的循環，這樣我就能夠把整個計算時間降低了十分之一以上。
寄存器變量
在聲明局部變量的時候可以使用 register 關鍵字。這就使得編譯器把變量放入一個多用選的寄存器，而不是堆棧里。合適地使用這種方琺，它會為編譯器提供關于最經常訪問變量的提示，會稍微提高函數的執行速度。函數調用得越是頻繁，這樣的改變就越是可能提高代碼的速度。
全局變量
使用全局變量比向函數傳遞參數更加有效率。這樣做去除了函數調用前參數入棧和函數完成后參數出棧的需要。實際上，任何子程序最有效率的實現是根本沒有參數。然而，決定使用全局變量對程序也可能有一些負作用。軟件工程人士通常不鼓勵使用全局變量，努力促進模塊化和重入目標，這些也是重要的考慮。
輪詢
中斷服務例程經常用來提高程序的效率。然而，也有少數例子由于過度和中斷關聯而造成實際上效率低下。在這些情況中，中斷間的平均時間和中斷的等待時間具有相同量級。這種情況下，利用輪詢與硬件設備通信可能會更好。當然，這也會使軟件的模塊更少。
定點運算
除非你的目標平臺包含一個浮點運算的協處理器，否則你會費很大的勁去操縱你程序中的浮點數據。編譯器提供的浮點庫包含了一組模仿浮點運算協處理器指令組的子程序。很多這種函數要花費比它們的整數運算函數更長的執行時間，并且也可能是不可重入的。
如果你只是利用浮點數進行少量的運算，那么可能只利用定點運算來實現它更好。雖然只是明白如何做到這一點就夠困難的了，但是理論上用定點運算實現任何浮點計算都是可能的。(那就是所謂的浮點軟件庫。)你最大的有利條件是，你可能不必只是為了實現一個或者兩個計算而實現整個IEEE 754 標準。如果真的需要那種類型的完整功能，別離開編譯器的浮點庫，去尋找其他加速你程序的方法吧。