經常有人問list資料量上萬的時候，更新效率很低的問題
事實上，對任何介面庫，資料量大到一定程度，優化都是必須的
有人提出了虛擬視窗的方法，就是list只維護少數item，滾動的時候根據顯示範圍調整這幾個item的顯示屬性。這也是個優化方法，而且能夠處理的資料量級理論上非常大。不過這種方法不是太通用，這裡提供的是乙個小技巧，針對幾萬資料是沒什麼問題的。
list的效率瓶頸主要體現在estimatesize函式計算上面，而針對estimatesize的優化，只需要給乙個預設值，就可以跳過複雜的大小計算了
在xml中放乙個唯一的list，然後新增如下**：
clistui* plist = static_cast(m_manager.findsubcontrolbytype(m_manager.getroot(), _t("list")));
dword c = plist->getcount();
for( int i = 0; i < 20000; ++i ) ;
_stprintf(szbuf, _t("text=\"%d交換list第乙個節點和最後乙個節點的位置\" height=\"26\" width=\"9999\""), c + i);
//_stprintf(szbuf, _t("text=\"%d交換list第乙個節點和最後乙個節點的位置\""), c + i); // 這樣寫效率明顯低很多
}兩種寫法，大家可以感受一下延遲差距
索引效率優化
索引是提高資料查詢最有效的方法，也是最難全面掌握的技術，因為正確的索引可能使效率提高10000倍，而無效的索引可能是浪費了資料庫空間，甚至大大降低查詢效能。索引的管理成本 1 儲存索引的磁碟空間 2 執行資料修改操作 insert update delete 產生的索引維護 3 在資料處理時回需額外...
索引效率優化
索引是提高資料查詢最有效的方法，也是最難全面掌握的技術，因為正確的索引可能使效率提高10000倍，而無效的索引可能是浪費了資料庫空間，甚至大大降低查詢效能。索引的管理成本 1 儲存索引的磁碟空間 2 執行資料修改操作 insert update delete 產生的索引維護 3 在資料處理時回需額外...
kafka 效率優化
資料分割槽儲存 在topic內設定了多個分割槽，使kafka的消費者程序池能得到有序性保證和負載均衡，使得topic對應的消費組裡的消費者們各自可以獨享乙個分割槽。如此的話，每個消費者是其消費的分割槽的唯一reader，在單個reader下當然保證了有序這件事。而且多個分割槽也使得負載可以比較平衡。...