私は Rx が大好きですが、常に問題に直面しています。
1 つのアップストリームシーケンスIObservable<Foo>
とN
ダウンストリーム シーケンスが関連付けられているとします。それぞれは、いくつかの単純な述語 (たとえばfoo.bar == someKey
) を満たす Foo にのみ関心があります。
もちろん、これは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
が非常に小さいことです。通常、それぞれに 1 つだけ存在しますFoo
。Foo
これは、これも伝播する必要があるいくつかの下流シーケンスを見つけるために非常に効率的なルックアップを実行できるときに、本質的に低速の線形検索を実行していることを意味します。私のアプリは非常にパフォーマンスが重要な環境で実行されており、この非効率性を許容することはできません。
これをより効率的に行うエレガントな方法を見つけようと頭を悩ませましたが、多くの状態を保存し (サブスクライバーのマッピングなど)、並行性を非常に慎重に管理する必要があるソリューションしか思いつきません。そもそもRxを使用する目的の多く。既存のオペレーターに関して、これに対処する何らかの方法を希望します。誰かが以前にこの問題に対処したことがありますか、または良い解決策を知っていますか? 詳細をお知らせいただければ幸いです。
編集
私の例は少し単純すぎたと思います。既知の範囲内の数値と照合するケースは扱っていません。N は説明目的でのみ使用されました。上記の更新された例。