先引用unix程式設計藝術第一章的一段話
rob pike，最偉大的c語言大師之一，在《nos on c programming》中從另乙個稍微不同的角度表述了unix的哲學
原則1：你無法判定程式會在什麼地方耗費執行時間。瓶頸經常出現在想不到的地方，所以別急於亂找個地方改**，除非你已經證實那兒就是瓶頸所在。
原則2：估量。在你沒對**進行估量，特別是沒有找到最耗時的那個部分之前，別去優化速度。
原則3：.......
......
根據大師的原則，我們必須找出整個hevc編碼框架中最耗時的地方，也就是整個編碼框架的瓶頸所在。由於hevc編碼結構的基礎cu，tu的是基於四叉樹的劃分，所以整個編碼框架是乙個遞迴的結構，編碼器的優化包括兩個方面
1.**和變換的快速模式選擇
2.關鍵瓶頸演算法的優化
第一條**和變換的快速模式選擇，我們講在後面的文章中進行討論，這篇文章我們先討論一下找出hevc編碼框架中最耗時的部分。
為了找到編碼框架中最耗時的演算法，我們把編碼的結構配置到最簡單，即cu和tu的層數都為1，不做遞迴的劃分，只做intra的編碼，配置如下：
#*****=== unit definition ***************=
maxcuwidth : 16 # maximum coding unit width in pixel
maxcuheight : 16 # maximum coding unit height in pixel
maxpartitiondepth : 1 # maximum coding unit depth
quadtreetulog2maxsize : 4 # log2 of maximum transform size for
# quadtree-based tu coding (2...6)
quadtreetulog2minsize : 3 # log2 of minimum transform size for
# quadtree-based tu coding (2...6)
quadtreetumaxdepthinter : 1
quadtreetumaxdepthintra : 1
cu的大小為16x16,tu的大小為8x8，開啟vs2010的效能分析工具，可以找到最耗時的幾個模組
1.rdoq 量化的率失真優化 15%以上
2.had harmand編碼的sad 20%
3.transform
4.quant
其中rdoq不是必須的模組，但是測試發現rdoq對編碼的效果有很大的提公升，在開啟rdoq的情況下，同等pnsr情況下位元速率會降低5%左右。
還好這幾個模組都可以很好的用simd來進行彙編優化，由此可見標準組織設計的巧妙。這些模組的具體演算法，後面將會有詳盡的論述。
python os模組中比較有用的部分
下面列出了一些在os模組中比較有用的部分。os.listdir 返回指定目錄下的所有檔案和目錄名 os.remove 函式用來刪除乙個檔案 os.removedirs 刪除多個目錄 os.path.isfile 檢驗給出的路徑是否是乙個檔案 os.path.isdir 檢驗給出的路徑是否是乙個目錄 ...
Java 中 比較的是什麼？
public class arraytest 顯然，儘管 a 與 b 物件的值相同，但是在記憶體中的位址是不同的，即兩個物件是不一樣的。再看乙個例子 public class arraytest 這是因為常量池的存在。而執行時常量池其實是屬於方法區的一部分。通俗的說，c 和 d 其實都是都是指向 a...
jstl在jsp中比較的
從servlet返回到jsp中是乙個集體 list list results.getdata 那麼它的每乙個物件就是乙個map。我在取其中的值進行比較時，出現了問題。問題報錯，原來是servlet在返回之前，先把2轉換成了對應的漢字，比較低階.變換一下 這就沒問題了。那麼如果servlet就直接返回...