@@ -64,6 +64,35 @@ computations, and the IO monad providing an escape hatch to an imperative
6464model, we just love to fall into the imperative trap, and start asking the same
6565fundamental question again - why do we have to use the streaming data model?
6666
67+## Comparative Performance
68+
69+High performance and simplicity are the two primary goals of streamly.
70+`Streamly` employs two different stream representations (CPS and direct style)
71+and interconverts between the two to get the best of both worlds on different
72+operations. It uses both foldr/build (for CPS style) and stream fusion (for
73+direct style) techniques to fuse operations. In terms of performance,
74+Streamly's goal is to compete with equivalent C programs. Streamly redefines
75+"blazing fast" for streaming libraries, it competes with lists and `vector`.
76+Other streaming libraries like "streaming", "pipes" and "conduit" are orders of
77+magnitude slower on most microbenchmarks. See [streaming
78+benchmarks](https://github.com/composewell/streaming-benchmarks) for detailed
79+comparison.
80+
81+The following chart shows a comparison of those streamly and list operations
82+where performance of the two differs by more than 10%. Positive y-axis displays
83+how many times worse is a list operation compared to the same streamly
84+operation, negative y-axis shows where streamly is worse compared to lists.
85+
86+
87+
88+Streamly uses lock-free synchronization for concurrent operations. It employs
89+auto-scaling of the degree of concurrency based on demand. For CPU bound tasks
90+it tries to keep the threads close to the number of CPUs available whereas for
91+IO bound tasks more threads can be utilized. Parallelism can be utilized with
92+little overhead even if the task size is very small. See [concurrency
93+benchmarks](https://github.com/composewell/concurrency-benchmarks) for detailed
94+performance results and a comparison with the `async` package.
95+
6796## Installing and using
6897
6998Please see
@@ -104,34 +133,6 @@ the semigroup operation `<>` is concurrent. This makes `foldMap` concurrent
104133too. You can replace `AsyncT` with `SerialT` and the above code will become
105134serial, exactly equivalent to a `ListT`.
106135
107−## Comparative Performance
108−
109−High performance and simplicity are the two primary goals of streamly.
110−`Streamly` employs two different stream representations (CPS and direct style)
111−and interconverts between the two to get the best of both worlds on different
112−operations. It uses both foldr/build (for CPS style) and stream fusion (for
113−direct style) techniques to fuse operations. Streamly redefines "blazing fast"
114−for streaming libraries, it competes with lists and `vector`. Other streaming
115−libraries like "streaming", "pipes" and "conduit" are orders of magnitude
116−slower on most microbenchmarks. See [streaming
117−benchmarks](https://github.com/composewell/streaming-benchmarks) for detailed
118−comparison.
119−
120−The following chart shows a comparison of those streamly and list operations
121−where performance of the two differs by more than 10%. Positive y-axis displays
122−how many times worse is a list operation compared to the same streamly
123−operation, negative y-axis shows where streamly is worse compared to lists.
124−
125−
126−
127−Streamly uses lock-free synchronization for concurrent operations. It employs
128−auto-scaling of the degree of concurrency based on demand. For CPU bound tasks
129−it tries to keep the threads close to the number of CPUs available whereas for
130−IO bound tasks more threads can be utilized. Parallelism can be utilized with
131−little overhead even if the task size is very small. See [concurrency
132−benchmarks](https://github.com/composewell/concurrency-benchmarks) for detailed
133−performance results and a comparison with the `async` package.
134−
135136## File IO
136137
137138The following code snippet implements some common Unix command line utilities