我喜歡Rx,但我遇到了一個問題,我一直在遇到。假設我們有一個上游IObservable<Foo>
和N
下游順序序列,其中每個序列只對滿足一些簡單謂詞(比如foo.bar == someKey
)的Foos感興趣。無功擴展:Where()的問題
當然這是針對Where()
操作一個簡單的工作:
IObservable<Foo> foos = ...;
foos.Where(foo => foo.bar == "abc").Subscribe(f => A(f));
foos.Where(foo => foo.bar == "xyz").Subscribe(f => B(f));
foos.Where(foo => foo.bar == "bla").Subscribe(f => C(f));
...
[many more subscriptions for different bar values]
什麼將主要發生在這裏的是,對上游生產的每個Foo
,該Where()
謂詞將爲該Foo
N
次評估。它像線性搜索一樣查找所有需要此訂戶的訂戶Foo
。這一切都很好,正是我們(應該)期待在這裏使用Where()
。
我的問題是,在我的情況下,N
可能非常大,但想要任何特定Foo
的用戶子集非常小。通常,每個Foo
將只有一個。這意味着我本質上是做一個緩慢的線性搜索,當我可以做一個非常有效的查找來找到這個Foo
需要傳播的少數下游序列。我的應用程序運行在非常關鍵的性能環境中,我無法承受這種低效率。
我已經絞盡腦汁想要找到一些更高效的優化方法,但我只能想出一些解決方案,這些解決方案涉及存儲大量狀態(映射訂戶等),並且必須非常小心地管理併發,這首先破壞了很多使用Rx的目的。我希望以現有的運營商的角度來處理這個問題。有沒有人處理過這個問題,或知道一個好的解決方案?我很高興提供更多細節。
編輯
我想我的例子是有點過於簡單化。我沒有處理與某些已知邊界內的數值匹配的情況。 N僅用於說明目的。上面的更新示例。
你會對所有可能的bar 0..N值,還是僅僅爲某些? – 2013-04-09 17:54:49
最好的可能是保持你的foos排序順序。看看'List.BinarySearch',然後只是迭代調用'Subscribe'直到'foo.Bar> = N' – 2013-04-09 18:16:41
對不起,我的例子太簡單了,請參閱編輯和新示例代碼。 – Tim 2013-04-09 19:14:26