今天看android原始碼時看到這樣一行**「return value * metrics.xdpi * (1.0f/72);」，感覺很奇怪，為什麼不直接除以72呢？難到手機上乘法比除法快，google一下找到了下面說明：
不要使用除法
您的遊戲專案不應該執行單獨的除法運算。arm 處理器本身不支援除法運算。每次您進行除法運算的時候，它都會消耗數千個時鐘週期。132 mhz 的 arm 在理論上可以每秒執行 1.32 億條指令（或者 2.64 億條指令，如果其中一半運算是移位運算）。但是每秒 7 萬次的除法運算就會超過 cpu 的最大能力。也就是說，如果您的遊戲執行速度是每秒 70 幀，則對所繪製的每一幀進行 1,000 次除法運算就會達到處理器的最大能力。
將所有除法都替換成移位和/或乘法運算。被 16 除可以改寫為右移 4 位。更複雜的除法運算可以用移位和/或乘法的組合運算實現。
也可以用查詢表來執行除法運算。不過，如果分子和分母都是 32 位，所需的二維查詢表就遠遠超出了可用的記憶體容量。一種解決方案就是縮小問題的範圍。
在表示式 a / b 中，可以在任何需要的位置插入乙個「乘以 1」而不改變最終結果。這樣 a * 1 / b 將產生完全相同的結果。另外也可以改變乘除法的順序，將其寫為 a * ( 1 / b )，這樣，除法運算就被簡化為 1 / b，它只需要乙個一維的查詢表。您還可以進一步簡化查詢表，方法是降低精度。我們先假設在大多數情況下 16 位的精度就已經足夠，您的查詢表只需要 64k 的項數。通過查詢 b 中的 msb（最高有效位），您可以使用此資訊對 b 和結果進行向上或向下的移位以調整您的 32 位數值，同時保持最高的可能精度。即使加上由於隨機訪問除法查詢表而造成的填充一條緩衝線的時間，最差的情況也將少於 100 個時鐘週期。這個結果是編譯器提供的標準除法效率的 20 倍，付出的代價是精度的一點點損失。
sql儲存過程比sql語句執行慢很多
引數嗅探的問題 原因 1 可能是發生了引數嗅探，第一次賦給儲存過程的輸入引數，會為該儲存過程生成乙個基於輸入引數的執行計畫，因此如果第一次輸入的引數不具有代表性 例如大部分查詢輸入的引數都是a值，但第一次執行儲存過程時輸入的是b值 就有可能比即席查詢慢，儘管即席查詢需要重新編譯執行計畫，但選擇了更有...
在arm上搭建flask執行環境
flask是乙個簡單的實用的web服務，由於其比較小巧，對於一些簡單需求的服務是比較方便的，如restful api。由於flask是乙個在python上執行的庫，所以想要執行flask，那麼乙個python庫是必不可少的，那麼就需要交叉編譯乙個python庫，可以參考 交叉編譯python 2.7...
執行儲存過程比即時SQL執行慢的解決方案
發生過這樣一件事，寫了乙個sql，查詢資料大概5秒，但是放到儲存過程裡面去了過後，查了5分鐘也沒給出結果，後來網上找解決方案，終於找到乙個解決方案。在儲存過程的引數那裡對引數進行乙個傳遞。反正他們說的引數嗅探是這個意思。這是儲存過程的機制。具體是什麼，大家去網上搜尋下。alter procedure...