Use --stream-size for all the array benchmarks now
Replace the following files:
- benchmark/Streamly/Benchmark/Data/Array.hs
- benchmark/Streamly/Benchmark/Data/ArrayOps.hs
- benchmark/Streamly/Benchmark/Data/Prim/Array.hs
- benchmark/Streamly/Benchmark/Data/Prim/ArrayOps.hs
- benchmark/Streamly/Benchmark/Data/SmallArray.hs
- benchmark/Streamly/Benchmark/Data/SmallArrayOps.hs
- benchmark/Streamly/Benchmark/Memory/Array.hs
- benchmark/Streamly/Benchmark/Memory/ArrayOps.hs
With:
- benchmark/Streamly/Benchmark/Array.hs
- benchmark/Streamly/Benchmark/ArrayOps.hs
Now they are in FileSystem.Handle module corresponding to the source module
with the same name. Also, now we have them arranged based on space complexity
so that we can apply RTS memory restrictions when running.
Also, now longer benchmarks use a shorter file.
* UndecidableInstances -- Don't want to use unless indicated
* TypeFamilies -- Causes large regressions and improvements
* UnboxedTuples -- interferes with (#.)
* Now benchmark modules correspond to source modules. The Prelude module in
source corresponds to several modules one for each stream type.
* Benchmarks in the same order/groupings as they appear in source
* All benchmarks now have division according to space complexity
* Refactoring reduces a lot of code duplication especially the stream
generation and elimination functions.
* The RTS options are now completely set in the shell script to run the
benchmarks.
* RTS options can be set on a per benchmark basis. RTS options work correctly
now.
* The set of streaming/infinite stream benchmarks is now complete and we can
run all such benchmarks coneveniently.
* Benchmark "quick"/"speed" options can now be specified on a per benchmark
basis. Longer benchmarks can have fewer iterations/quick run time.
* Benchmarks are grouped in several groups which can be run on a per group
basis. Comparison groups are also defined for convenient comparisons of
different modules (e.g. arrays or streamD/K).
* The benchmark namespaces are grouped in a consistent manner. Benchmark
executables have a consistent naming based on module names.
CPS performs much better for parsing operations like "sequence" and
"choice" on large containers. Given that applicative "sequence" does
not scale, I guess the Monad instance as well won't scale for direct
implementation.
This is the initial version of stream parsing. It implements a "Parse"
type, some parsers based on that type, applicative composition, operations to
run parsers (parse) and to run parsers over chunks of a stream (parseChunks).
Parsers are just an extension of Folds in Streamly.Data.Fold. Parsers just add
backtracking and failure capabilities to folds.
Operations like splitOn to split a stream on a predicate can now be expressed
using a parser applied repeatedly on a stream. For example, line splitting can
be done using parsers. Parsers are as fast as fastest custom code for
line splitting.
* move common modules to lib directory. This is required because otherwise
cabal/ghc would try to use them directly and emit warnings about
missing-modules.
* move the prelude benchmark executables to Streamly/Benchmark/Prelude
to be consistent with the organization of other modules.
Benchmarks are divided into 4 categories:
1) using O(1) space
2) using O(n) Heap
3) using O(n) stack
4) using O(n) heap and stack
This allows us to run the benchmark executables with restricted heap
and stack memory limites so that we can catch space leak issues or high
space usage issues quickly.