S>По-моему, их можно будет свести к минимуму, как в скорости, так и в памяти.
Я над этим отдельно работал

S>К примеру, можно вообще не подписываться на события "завёрнутой" коллекции до тех пор, пока на наши события никто не подписан.
S>Тогда никаких лишних вызовов производиться не будет.
Возможно пользователь не нужно подписываться на события вычисляемой коллекции. Ему просто нужно чтобы всегда "под рукой" была вычисленная коллекция. Например, если вычисление сложное и\или коллекции источники большие, каждый раз вычислять коллекцию обычным LINQ не хочется по соображениям производительности. Например, есть Dictionaring. Его можно рассматривать как самообновляемый словарь, событий у него нет. Такой выигрыш в производительности ещё один сценарий использования OC, кроме событий. Кстати забыл упомянуть этот сценарий в документации.

S>А размер памяти, потребляемой "observable" результатом select или where будет ненамного больше, чем у результата обычного linq-to-objects запроса.
То же надо оценивать.

S>По-моему, их можно будет свести к минимуму, как в скорости, так и в памяти.
Я над этим отдельно работал

S>К примеру, можно вообще не подписываться на события "завёрнутой" коллекции до тех пор, пока на наши события никто не подписан.
S>Тогда никаких лишних вызовов производиться не будет.
Возможно пользователю не нужно подписываться на события вычисляемой коллекции. Ему просто нужно чтобы всегда "под рукой" была вычисленная коллекция. Например, если вычисление сложное и\или коллекции источники большие, каждый раз вычислять коллекцию обычным LINQ не хочется по соображениям производительности. Например, есть Dictionaring. Его можно рассматривать как самообновляемый словарь, событий у него нет. Такой выигрыш в производительности ещё один сценарий использования OC, кроме событий. Кстати забыл упомянуть этот сценарий в документации.

S>А размер памяти, потребляемой "observable" результатом select или where будет ненамного больше, чем у результата обычного linq-to-objects запроса.
То же надо оценивать.