What are the actual advantages of Observable over Flowable?

Question

What's different in 2.0 describes the differences between Observable and Flowable. However, Observable is mostly described in terms of features that it lacks in comparison to Flowable. There is only one distinguishing feature of Observable mentioned:

Using Observable has lower overhead in general than Flowable.

But even this seems to be contradicted by the suggestion that Observable is preferable for small numbers of elements and is more likely to lead to an OutOfMemoryError if tasked too heavily. This seems to suggest that Flowable is generally more efficient.

The other thing I find confusing is that if Observable is preferred for use cases with fewer than 1K elements, and Flowable is preferred for use cases with over 10K elements, then use cases having between 1K and 10K elements are a gray area.

Is there a more technical explanation of the differences between Observable and Flowable? Especially one that suggests a practical heuristic for deciding which to use in the gray area between 1K and 10K elements, or when the number of elements is unknown or may change.

Related: This Q&A only quotes the documentation without further explanation.

Answer 1

Is there a more technical explanation of the differences between Observable and Flowable?

I'll give you one but most people get scared by the technical details.

However, Observable is mostly described in terms of features that it lacks in comparison to Flowable.

Yes, because technically Observable is Flowable minus the backpressure related request coordination logic on all of its operators.

But even this seems to be contradicted by the suggestion ...

There is no contradiction, getting values through an Observable from one end to the other encounters less "resistance" because the logic doesn't have to deal with request coordination or temporary buffering. For example, Observable.flatMapIterable doesn't have to queue up source items because each inner Iterable can be streamed in its entirety immediately from the onNext. Flowable has to queue items, trampoline the draining and Iterable item emission and limit it to the requested amount in a fairly expensive queue-drain logic compared to a straight emission.

This seems to suggest that Flowable is generally more efficient.

There is a tradeoff between memory usage (thus GC overhead) and latency.

Then use cases having between 1K and 10K elements are a gray area.

It means that between the two numbers, you may need to find other decision variables, such as individual element size, expected latency, what's the rest of your app/system doing, etc.

or when the number of elements is unknown or may change

The case for Observable uses the word "longest", that means at any given time, you have a possibly buffered sequence of 1000 elements or less, or alternatively, your source emits at most 1 element per millisecond on average.

This is otherwise a typical "depends" case:

• Can the source be reasonably backpressured?
• Is the processing logic generally slower than the source or its upper stages?
• Do different subscribers encounter different number of elements?
• Is the environment constrained in some way?
• Are the items relatively large?

If you can answer with yes to these questions, you are better off with Flowable.