-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quadratic performance on left-associated binds #234
Comments
[N.B. conduit doesn't have quadratic performance. I made a mistake when setting up the benchmarks: tomjaguarpaw/streaming-benchmark@2a965a7] |
For what it's worth, this is mentioned in the tutorial: https://hackage.haskell.org/package/pipes-4.3.16/docs/Pipes-Tutorial.html#g:10 Here's an old ticket about it: #100 |
Thanks for pointing that out. My comments:
|
I don't have plans to fix this myself, but I'd accept a pull request if it didn't lead to a significant performance regression for other benchmarks |
Which sort of change would you accept? Previously you said you would prefer not to CPS the internal representation. The alternative is to add a |
|
Thanks Gabriella. To clarify, I don't have plans to fix this either but I think it's helpful to have the requirements spelled out like this in case anyone else wants to take it on. |
The problem
Consider walking over a tree using a streaming library to do something at every leaf:
On left-skewed trees, i.e. trees that will end up generating left-associated binds, for example those generated by
leftSkewed
the performance of your streaming library is quadratic. In fact performance is quadratic under
(Neither streamly nor conduit have quadratic performance)
The plot below demonstrates the claim. The code to generate the plot is available at https://github.com/tomjaguarpaw/streaming-benchmark. The compiler was GHC 8.10.7.
The solution
Firstly, before talking about a solution, do you actually consider this a bug? I do, and I think the risk of hitting unexpected quadratic performance makes this library unsuitable for production use as it is. On the other hand maybe you have a good reason that I shouldn't think that. If so I would be interested to hear it.
If you do think this is a bug then let's think about what can be done. I know of two straightforward options:
Codensity
(streamly essentially uses handwrittenCodensity
.)In my benchmarks explicit bind comes out slightly ahead. (The examples are implemented to match
streaming
but the same techniques ought to apply to your library.)Perhaps there is another option more suitable for your library.
I welcome your thoughts.
(Related to #131)
The text was updated successfully, but these errors were encountered: