service-benchmark-tool
Benchmarks for System.Timeout
- Results
- Timeout.html
- Code
- Timeout.hs
These benchmarks evaluate the performance of timeout
when used for many
short-running sequential actions from a moderate number of concurrent
threads.
In concrete the benchmarks spawn 16 concurrent threads and have each
sequentially repeat the same action 1000 times. The action consists of n
sequential calls to getCurrentTime
. The benchmarks are executed for
different values for n
.
We compare four different setups:
-
Just execute the basic setup precisly as described above.
-
Each action of
n
calls togetCurrentTime
is wrapped into a call totimeout
. The timeout parameter is chosen large enought so that it won’t trigger. -
Each action of
n
calls togetCurrentTime
is started only after updating anMVar
that is shared by all threads. The update is a cheap, but not yet trivial pure function. -
Each action of
n
calls togetCurrentTime
is started only after atomically updating anIORef
that is shared by all threads. The update is a cheap, but not yet trivial pure function.
Note that the third and the fourth scenario force a synchronization between all threads, whereas, to the best of my knowledge, the call to timeout only requires synchronization between all threads on the same capability.
Usage:
cd test/Timeout
ghc --make -threaded Timeout.hs -rtsopts -O -fforce-recomp -Wall
./Timeout -o Timeout.html +RTS -N8
http-streams versus http-client
- Results
- first results set and second results set
- Code
- StreamsVsClient.hs
- README
- README.md
A more detailed description of the results is published in this gist and discussed in this issue of http-client.
Usage:
cd test/StreamsVsClient
ghc --make -O2 StreamsVsClient.hs -Wall -fforce-recomp -threaded
./StreamsVsClient -o StreamsVsClient.html +RTS -N