首先需要明確一點，不要過早的優化代碼，這是很多大師的忠告。
代碼先保證正確，然後再考慮優化
這並不意味著用8周時間寫一個全功能的射線追蹤算法，然後用8周時間去優化它。
分多步來做性能優化。
先寫正確的代碼，當你意識到這個函數可能會被經常調用，進行明顯的優化。
然後再尋找算法的瓶頸，並解決（通過優化或者改進算法）。通常，改進算法能顯著地改進瓶頸——也許是采用一個你還沒有預想到的方法。所有頻繁調用的函數，都需要優化。
我所了解的那些寫出非常高效代碼的人說，他們優化代碼的時間，是寫代碼時間的兩倍。
跳轉和分支執行代價高，如果可能，盡量少用。
函數調用需要兩次跳轉，外加棧內存操作。
優先使用迭代而不是遞歸。
使用內聯函數處理短小的函數來消除函數調用開銷。
將循環內的函數調用移動到循環外(例如，將for(i=0;i<100;i++) DoSomething();改為DoSomething() { for(i=0;i<100;i++) { … }})。
if…else if…else if…else if…很長的分支鏈執行到最後的分支需要很多的跳轉。如果可能，將其轉換為一個switch聲明語句，編譯器有時候會將其轉換為一個表查詢單次跳轉。如果switch聲明不可行，將最常見的場景放在if分支鏈的最前面。
仔細思考函數下標的順序。
兩階或更高階的數組在內存中還是以一維的方式在存儲在內存中，這意味著（對於C/C++數組）array[i][j] 和 array[i][j+1]是相鄰的，但是array[i][j] 和array[i+1][j]可能相距很遠。
以適當的方式訪問存儲實際內存中的數據，可以顯著地提升你代碼的執行效率（有時候可以提升一個數量級甚至更多）。
現代處理器從主內存中加載數據到處理器cache，會加載比單個值更多的數據。該操作會獲取請求數據和相鄰數據（一個cache行大小）的整塊數據。這意味著，一旦array[i][j]已經在處理器cache中，array[i][j+1]很大可能也已經在cache中了，而array[i+1][j]可能還在內存中。
避免或減少使用本地變量。
本地變量通常都存儲在棧上。不過如果數量比較少，它們可以存儲在CPU寄存器中。在這種情況下，函數不但得到了更快訪問存儲在寄存器中的數據的好處，也避免了初始化一個棧幀的開銷。
不要將大量數據轉換為全局變量。
減少函數參數的個數。
和減少使用本地變量的理由一樣——它們也是存放在棧上。
通過引用傳遞結構體而不是傳值
我在射線追蹤中還找不到一個場景需要將結構體使用傳值方式（包括一些簡單結構如：Vector，Point和Color）。
如果你的函數不需要返回值，不要定義一個。
盡量避免數據轉換。
整數和浮點數指令通常操作不同的寄存器，所以轉換需要進行一次拷貝操作。
短整型（char和short）仍然使用一整個寄存器，並且它們需要被填充為32/64位，然後在存儲回內存時需要再次轉換為小字節（不過，這個開銷一定比一個更大的數據類型的內存開銷要多一點）。
定義C++對象時需要注意。
使用類初始化而不是使用賦值（Color c(black); 比Color c; c = black;更快）
使類構造函數盡可能輕量。
尤其是常用的簡單類型（比如，color，vector，point等等），這些類經常被復制。
這些默認構造函數通常都是在隱式執行的，這或許不是你所期望的。
使用類初始化列表(Use Color::Color() : r(0), g(0), b(0) {}，而不是初始化函數Color::Color() { r= g = b = 0; } .)
如果可以的話，使用位移操作>>和<<來代替整數乘除法
小心使用表查找函數
許多人都鼓勵將復雜的函數（比如：三角函數）轉化為使用預編譯的查找表。對於射線追蹤功能來說，這通常導致了不必要的內存查找，這很昂貴（並不斷增長），並且這和計算一個三角函數並從內存中獲取值一樣快（尤其你考慮到三角查找打亂了cpu的cache存取）。
在其他情況下，查找表會很有用。對於GPU編程通常優先使用表查找而不是復雜函數。
對大多數類，優先使用+= 、 -= 、 = 和 /=，而不是使用+ 、 – 、 、 和?/
這些簡單操作需要創建一個匿名臨時中間變量。
例如：Vector v = Vector(1,0,0) + Vector(0,1,0) + Vector(0,0,1);?創建了五個匿名臨時Vector: Vector(1,0,0), Vector(0,1,0), Vector(0,0,1), Vector(1,0,0) + Vector(0,1,0), 和 Vector(1,0,0) + Vector(0,1,0) + Vector(0,0,1).
對上述代碼進行簡單轉換：Vector v(1,0,0); v+= Vector(0,1,0); v+= Vector(0,0,1);僅僅創建了兩個臨時Vector: Vector(0,1,0) 和 Vector(0,0,1)。這節約了6次函數調用（3次構造函數和3次析構函數）。
對於基本數據類型，優先使用+?、?-?、??、?和?/，而不是+=?、?-=?、?= 和 /=
推遲定義本地變量
定義一個對象變量通常需要調用一次函數（構造函數）。
如果一個變量只在某些情況下需要（例如在一個if聲明語句內），僅在其需要的時候定義，這樣，構造函數僅在其被使用的時候調用。
對於對象，使用前綴操作符（++obj），而不是後綴操作符（obj++）
這在你的射線追蹤算法中可能不是一個問題
使用後綴操作符需要執行一次對象拷貝（這也導致了額外的構造和析構函數調用），而前綴的構造函數不需要一個臨時的拷貝。
小心使用模板
對不同的是實例實現進行不同的優化。
標准模板庫已經經過良好的優化，不過我建議你在實現一個交互式射線追蹤算法時避免使用它。
使用自己的實現，你知道它如何使用算法，所以你知道如何最有效的實現它。
最重要的是，我的經歷告訴我：調試STL庫非常低效。通常這也不是一個問題，除非你使用debug版本做性能分析。你會發現STL的構造函數，迭代器和其他一些操作，占用了你15%的運行時間，這會導致你分析性能輸出更加費勁。
避免在計算時進行動態內存分配
動態內存對於存儲場景和運行期間其他數據都很有用。
但是，在許多（大多數）的系統動態內存分配需要獲取控制訪問分配器的鎖。對於多線程應用程序，現實中使用動態內存由於額外的處理器導致了性能下降，因為需要等待分配器鎖和釋放內存。
即便對於單線程應用，在堆上分配內存也比在棧上分配內存開銷大得多。操作系統還需要執行一些操作來計算並找到適合尺寸的內存塊。
找到你系統內存cache的信息並利用它們
如果一個是數據結構正好適合一個cache行，處理整個類從內存中只需要做一次獲取操作。
確保所有的數據結構都是cache行大小對齊（如果你的數據結構和一個cache行大小都是128字節，仍有可能因為你的結構體中的一個字節在一個cache行中，而其他127字節在另外一個cahce行中）。
避免不需要的數據初始化
如果你需要初始化一大段的內存，考慮使用memset。
盡早結束循環和盡早返回函數調用
考慮一個射線和三角形交叉，通常的情況是射線會越過三角，所以這裡可以優化。
如果你決定將射線和三角面板交叉。如果射線和面板交叉t值是負數，你可以立即返回。這允許你跳過射線三角交叉一大半的質心坐標計算。這是一個大的節約，一旦你知道這個交叉不存在，你就應該立即返回交叉計算函數。
同樣的，一些循環也應該盡早結束。例如，當設置陰影射線，對於近處的交叉通常都是不必須的，一旦有類似的的交叉，交叉計算就應該盡早返回。（這裡的交叉含義不太明白，可能是專業詞匯，譯者注）
在稿紙上簡化你的方程式
許多方程式中，通常都可以或者在某些條件中取消計算。
編譯器不能發現這些簡化，但是你可以。取消一個內部循環的一些昂貴操作可以抵消你在其他地方的好幾天的優化工作。
整數、定點數、32位浮點數和64位雙精度數字的數學運算差異，沒有你想象的那麼大
在現代CPU，浮點數運算和整數運算差不多擁有同樣的效率。在計算密集型應用（比如射線追蹤），這意味這可以忽略整數和浮點數計算的開銷差異。這也就是說，你不必要對算數進行整數處理優化。
雙精度浮點數運算也不比單精度浮點數運算更慢，尤其是在64位機器上。我在同一台機器測試射線追蹤算法全部使用double比全部使用floats運行有時候更快，反過來測試也看到了一樣的現象（這裡的原文是：I have seen ray tracers run faster using all doubles than all floats on the same machine. I have also seen the reverse）。
不斷改進你的數學計算，以消除昂貴的操作
sqrt()經常可以被優化掉，尤其是在比較兩個值的平方根是否一致時。
如果你重復地需要處理 除x 操作，考慮計算1/x的值，乘以它。這在向量規范化（3次除法）運算中贏得了大的改進，不過我最近發現也有點難以確定的。不過，這仍然有所改進，如果你要進行三次或更多除法運算。
如果你在執行一個循環，那些在循環中執行不發生變化的部分，確保提取到循環外部。
考慮看看你的計算值是否可以在循環中修改得到（而不每次都重新開始循環計算）。
接下來的博客，我們會對每一條進行更加詳細的解讀。coming!
