General purpose and usefuleness of StreamT<M, A>

[NonExisto]

From what I saw in Samples in the source code as well as in announcement here StreamT<M, A> is a monad wrapper around IEnumerable. For a pure value it behaves like IO, but it aren't seems to be its primary purpose. After spending some time debugging its implementation using unit tests some suspicious raised in my head regarding it usefulness and performance in comparison with other means exists in .net. So I created a simple benchmark over there to measure its actual performance. I'm running it on .net9

Method	N	Mean	Error	StdDev	Median	Rank	Allocated
EnumerableLast	10	6.967 ns	0.1484 ns	0.1239 ns	6.933 ns	1	40 B
ObservableLast	10	752.449 ns	1.8464 ns	1.4415 ns	752.033 ns	4	864 B
IterableLast	10	147.070 ns	1.6279 ns	1.5227 ns	146.537 ns	2	816 B
StreamTLast	10	3,056.516 ns	35.4507 ns	33.1606 ns	3,064.432 ns	6	11672 B
EnumerableLast	50	6.973 ns	0.0902 ns	0.0800 ns	6.955 ns	1	40 B
ObservableLast	50	2,657.520 ns	11.5929 ns	10.2768 ns	2,660.097 ns	5	2144 B
IterableLast	50	427.732 ns	5.8656 ns	5.4867 ns	426.826 ns	3	2896 B
StreamTLast	50	10,763.968 ns	154.2337 ns	144.2703 ns	10,711.313 ns	8	43192 B
EnumerableLast	100	7.094 ns	0.1551 ns	0.2368 ns	6.947 ns	1	40 B
ObservableLast	100	5,017.879 ns	8.7585 ns	8.1927 ns	5,018.227 ns	7	3744 B
IterableLast	100	764.590 ns	2.6577 ns	2.4860 ns	763.679 ns	4	5472 B
StreamTLast	100	19,890.513 ns	144.6427 ns	120.7832 ns	19,870.734 ns	9	82688 B

Don't get me wrong, I'm pretty sure, this type was very challenging to create. But most of its samples are easier to do with LINQ for objects and LINQ performance is Way better. So, does it worth our attention and maintenance effort?

[micmarsh]

I'm not Paul, but I believe the purpose of StreamT is precisely that it "behaves like IO"; you can stream and transform values akin to an Observable, but can also run side effects in a principled, functional way. The value proposition is thus, like the entirety of the rest of the library, more related to composability and maintainability of client code, and other qualitative things, rather than specific quantitative measures necessarily (although there's always room for improvement).

Since the purpose and usefulness of StreamT thus bound up with the usefulness of the IO monad in general, It's not surprising that very basic collection processing tasks, such as retrieving the last value, are more performant using types more specialized to said collection processing.

[NonExisto]

Well, perhaps my obsession with performance is indeed not worth it. Just made another benchmark for a Trampoline over there and it shows same overhead degradation magnitude for a way simpler class:🙌

BenchmarkDotNet v0.14.0, Windows 11 (10.0.22631.4460/23H2/2023Update/SunValley3)
AMD Ryzen 7 PRO 4750U with Radeon Graphics, 1 CPU, 16 logical and 8 physical cores
.NET SDK 9.0.100
  [Host]     : .NET 9.0.0 (9.0.24.52809), X64 RyuJIT AVX2
  DefaultJob : .NET 9.0.0 (9.0.24.52809), X64 RyuJIT AVX2

Method	N	Mean	Error	StdDev	Rank	Allocated
EnumerableFib	10	128.5 ns	0.34 ns	0.26 ns	1	352 B
RecursiveFib	10	200.0 ns	0.47 ns	0.39 ns	2	992 B
TrampolineFib	10	2,469.1 ns	48.45 ns	53.85 ns	7	13392 B
EnumerableFib	50	296.3 ns	4.25 ns	3.77 ns	3	672 B
RecursiveFib	50	1,073.7 ns	11.66 ns	10.33 ns	5	4624 B
TrampolineFib	50	68,071.2 ns	74.88 ns	66.38 ns	8	324544 B
EnumerableFib	100	494.4 ns	1.10 ns	0.92 ns	4	1072 B
RecursiveFib	100	2,306.6 ns	2.56 ns	2.39 ns	6	10192 B
TrampolineFib	100	295,933.2 ns	4,069.93 ns	3,398.57 ns	9	1290512 B

At lease Trampoline was way easier to use😊

[louthy]

I've marked @micmarsh's answer as the correct one. But, just to expand:

StreamT<M, A> is a monad wrapper around IEnumerable

This is not true.

For a pure value it behaves like IO

This is not true.

But most of its samples are easier to do with LINQ for objects

This is not true.

and LINQ performance is Way better

Only partially true. Seeing as LINQ for Objects can't actually do what this does.

@micmarsh got it absolutely right. Although this isn't only to do with IO, it is completely general purpose, it just happens to be most useful for lifting side-effects like IO, Eff, etc.

This is a monad transformer that can lift anything. It doesn't have to be IO, it can be any monad-type, or any monad-transformer stack. You cannot do that with a regular IEnumerable without having to manually manage the lifted monad (so, for IEnumerable<IO<A>> it would mean manually running the IO:

IEnumerable<IO<int>> mmx = // create an enumerable of IO;

var mmr = mmx.Select(mx => IO.pure(mx.Run(XXX) * 10))
             .Select(mx => IO.pure(mx.Run(XXX) + 1));

Where the XXX is, is where the EnvIO should go, with its cancellation-token, resource-dictionary, execution context, etc. That is all handled automatically by StreamT, maybe you could explain to me exactly how you would provide that with your LINQ-To-Objects solution? And once you've come up with that solution, come up with the solution -- in a general purpose way -- that works for ReaderT, StateT, Eff, and every future as-yet-unwritten monad that could be lifted into StreamT.

The above code looks like this for StreamT:

StreamT<IO, int>> mx = // create a stream of IO;

var mr = mx.Map(x => x * 10)
           .Map(x => x + 1);

some suspicious raised in my head regarding it usefulness

You don't understand what it does. And so, coming here to tell me I'm doing it wrong, like I have no idea what I'm doing, is really not going to sit well with me. You didn't even write your benchmarks accurately. None of the non-StreamT benchmarks lifts the IO monad and runs them at each stage. So, you're not even remotely comparing like-for-like. I am not going to waste my time replicating it, but the difference would be smaller. I would never expect the performance to be the same though, because this actively does more work to support the coroutines.

The critical thing that you miss is what @micmarsh points out:

"akin to an Observable, but can also run side effects in a principled, functional way. The value proposition is thus, like the entirety of the rest of the library, more related to composability and maintainability of client code, and other qualitative things, rather than specific quantitative measures necessarily"

This is exactly the correct point. We give up some processing to have code that we can maintain for the long-term. We give up some processing to have code that we can compose with other previously written code, making it easier for us to read and write code.

It is also expected that the thing that gets lifted is a side-effecting operation, like IO. The thing you're less likely to be worried about is the cost of a list iteration if each iteration invokes a web-request, or reads a file, or whatever.

And finally, this is a brand new feature. It is in beta. I am still working on it. And I will improve the performance over time. But the most important thing right now is that it is correct. There are performance limitations to the approach, but there's probably some additional gains to be made. Developers who know me well know that when it comes to hardcore performance tuning, I'm one of the best (a side-effect of my history). If there are gains to be made, I'll find them. Right now though, it just isn't a priority.

My suggestion to you is that before you start picking apart bits of this library, you try to fundamentally understand what it's about. You wouldn't be suggesting these things if you fully understood what StreamT actually does and why it's useful for type and function composition. And when StreamT is Run it yields the monad that it lifts, which none of your examples do; this fact makes it much easier to compose the results outside of StreamT too. Again, something that you ignore in your suggestions.

It will always be possible to write handwritten boilerplate-ridden solutions that are faster than the general-purpose types and functions in this library. You could improve the performance of your IEnumerable solution by using a foreach. Or even a pre-computed constant. But the code-bases that have handwritten boilerplate-ridden code are harder to maintain.