我訂閱了一個數據饋送,並且使用INSERT/DELETE消息中的索引值創建和維護一個結構。我想問一下組裝的cognoscenti是否知道任何能夠以有效的方式處理零碎更新的算法 - 通常批量更新包含兩到六個這樣的消息。一個數組的高效插入/刪除算法
該陣列的估計大小約爲1000個元素。
批量更新以按索引排序的消息列表到達,該列表規定在給定索引處插入或刪除項目。我希望陣容中的大部分流失比起始時期更接近開始。
在我看來,通過一些基本的處理過程,我可以確定受批次影響的範圍和整體大小 - 增量,因此只需移動一次未受影響的尾部。
同樣,我可以在第一個元素之前和最後一個元素之後保留一定量的可用空間,以儘可能減少複製量。
其他的優化包括:識別更新,如下列:
DELETE 10, INSERT 10 - effectively a replace which requires no copying
INSERT 10, DELETE 11 - as above
DELETE 10, DELETE 10, DELETE 10 - bulk deletion can be optimised into one copy operation
INSERT 11, INSERT 12, INSERT 13 - bulk insertion can be optimised into one copy operation
等。
但是,我很擔心執行識別步驟的開銷 - 它帶有前瞻性和追溯性,這可能比單純執行復制要花費更多的時間。
考慮到數組的預期大小,樹結構看起來很重:一些基本的性能測試表明,二進制或自平衡樹(在本例中是紅黑樹列表實現)僅在開始顯示性能優勢後纔開始顯示15K - 20K元素:在較小尺寸下,陣列副本顯着更快。我應該補充一點,我在這個實現中使用了Java。
任何提示,提示或建議將受到歡迎。
乾杯
邁克
在你談論速度的各種評論,但你甚至基準的結果?當處理使用非常繁重的列表(大約15個線程)時,我意外地搞砸了刪除方法,列表增長到大約100,000個元素。我的應用程序運行良好。我相信你們也會。 – TheLQ 2010-09-01 20:59:42