我喜欢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