From 5668b4f3a71d44bd3b7d7615fb1dcb3ccf72d10a Mon Sep 17 00:00:00 2001 From: Harendra Kumar Date: Tue, 30 Jul 2019 02:49:24 +0530 Subject: [PATCH] update performance section --- README.md | 37 +++++++++++++++++++----------- charts-0/KeyOperations-time.svg | 3 --- charts-0/streamly-vs-list-time.svg | 3 +++ 3 files changed, 27 insertions(+), 16 deletions(-) delete mode 100644 charts-0/KeyOperations-time.svg create mode 100644 charts-0/streamly-vs-list-time.svg diff --git a/README.md b/README.md index bf55dc2a..bbb5637c 100644 --- a/README.md +++ b/README.md @@ -104,23 +104,34 @@ the semigroup operation `<>` is concurrent. This makes `foldMap` concurrent too. You can replace `AsyncT` with `SerialT` and the above code will become serial, exactly equivalent to a `ListT`. -## How does it perform? +## Comparative Performance -Providing monadic streaming and high level declarative concurrency does not -mean that `streamly` compromises with performance in any way. The -non-concurrent performance of `streamly` competes with lists and the `vector` -library. The concurrent performance is as good as it gets, see [concurrency +High performance and simplicity are the two primary goals of streamly. +`Streamly` employs two different stream representations (CPS and direct style) +and interconverts between the two to get the best of both worlds on different +operations. It uses both foldr/build (for CPS style) and stream fusion (for +direct style) techniques to fuse operations. Streamly redefines "blazing fast" +for streaming libraries, it competes with lists and `vector`. Other streaming +libraries like "streaming", "pipes" and "conduit" are orders of magnitude +slower on most microbenchmarks. See [streaming +benchmarks](https://github.com/composewell/streaming-benchmarks) for detailed +comparison. + +The following chart shows a comparison of those streamly and list operations +where performance of the two differs by more than 10%. Positive y-axis displays +how many times worse is a list operation compared to the same streamly +operation, negative y-axis shows where streamly is worse compared to lists. + +![Streamly vs Lists (time) comparison](charts-0/streamly-vs-list-time.svg) + +Streamly uses lock-free synchronization for concurrent operations. It employs +auto-scaling of the degree of concurrency based on demand. For CPU bound tasks +it tries to keep the threads close to the number of CPUs available whereas for +IO bound tasks more threads can be utilized. Parallelism can be utilized with +little overhead even if the task size is very small. See [concurrency benchmarks](https://github.com/composewell/concurrency-benchmarks) for detailed performance results and a comparison with the `async` package. -The following chart shows a summary of the cost of key streaming operations -processing a million elements. The timings for `streamly` and `vector` are in -the 600-700 microseconds range and therefore can barely be seen in the graph. -For more details, see [streaming -benchmarks](https://github.com/composewell/streaming-benchmarks). - -![Streaming Operations at a Glance](charts-0/KeyOperations-time.svg) - ## File IO The following code snippet implements some common Unix command line utilities diff --git a/charts-0/KeyOperations-time.svg b/charts-0/KeyOperations-time.svg deleted file mode 100644 index b7b6379b..00000000 --- a/charts-0/KeyOperations-time.svg +++ /dev/null @@ -1,3 +0,0 @@ - - \ No newline at end of file diff --git a/charts-0/streamly-vs-list-time.svg b/charts-0/streamly-vs-list-time.svg new file mode 100644 index 00000000..3e81a877 --- /dev/null +++ b/charts-0/streamly-vs-list-time.svg @@ -0,0 +1,3 @@ + + \ No newline at end of file