Summary:
Add benchmarks for sequential and parallel writes.
Ran the benchmark for 10^6 writes
parallel - 0.19s
seq - 0.07s
Running in parallel probably has more contention for the IORef
Reviewed By: simonmar
Differential Revision: D14386951
fbshipit-source-id: 164972e714eac14406fc106df073474d141e9ca0
Summary:
Here I try to populate the writes done as part of a Haxl computation
in an IORef inside the Environment.
`IVar` which is the synchornisation point,
also acts as the point where we store intermediate writes for Haxl
computations, so they can be memoized and reused whenever a memoized
computation is done again. This is done inside `getIVarWithWrites` function.
This works, because we create new IVars when running a memo computation
or a data fetch, and it is only at these places where we need to create a new
environment with empty writes to run the computation in. So I run every memoized
computation in a new environment (with empty writes) and populate the writes in this new
environment. At the end of the memoized computation, I look up these writes from the `IVar`
and also add them to the original environment. This way ultimately all writes are correctly
propagated upwards to the top level environment user passes to `runHaxl`.
This logic lives inside `execMemoNow`.
Reviewed By: simonmar
Differential Revision: D14342181
fbshipit-source-id: a410dae1a477f27b480804b67b2212e7500997ab
Summary:
Now that the Haxl 2 diff has landed, I wanted to take the opportunity to reorganise the codebase.
I split parts of `Haxl.Core.Types` out into
* `Haxl.Core.Flags`, the `Flags` type and functions
* `Haxl.Core.DataSource`: the `DataSource` class and related stuff
and I split the massive `Haxl.Core.Monad` module into smaller modules:
* the base `Haxl.Core.Monad` with the types and instances
* `Haxl.Core.Fetch`: data-fetching functionality
* `Haxl.Core.Run`: the scheduler, and `runHaxl`
* `Haxl.Core.Profile`: profiling
* `Haxl.Core.Parallel`: `pAnd` and `pOr`
* I've also moved all the memoization support into `Haxl.Core.Memo`.
This commit also fixes the build on GHC 7.8.x, 7.10.x, and 8.2.x, all the Travis builds are green again.
Closes https://github.com/facebook/Haxl/pull/79
Reviewed By: zilberstein
Differential Revision: D6030246
Pulled By: simonmar
fbshipit-source-id: 5a0dc708cf72f8ed0906f1e99000976dbfbc89e2
Summary:
This is a complete reworking of the way that Haxl schedules I/O. The
main benefits are:
* Data fetches are no longer organised into rounds, but can be
arbitrarily overlapped with each other and with computation. The
scheduler supports an arbitrary queue of work items which it can
evaluate while data-fetching is taking place in the background. To
take advantage of this, data sources must implement a new form of
`PerformFetch`, namely `BackgroundFetch`. The old forms of
`PerformFetch` are still supported, but won't benefit from any
additional concurrency.
* It is now possible to specify on a per-data-source basis whether
fetching should be optimised for batching or for latency. A request
to a data source that doesn't benefit from batching can be submitted
immediately. This is done with the new `schedulerHint` method of
`DataSource`.
Reviewed By: niteria
Differential Revision: D4938005
fbshipit-source-id: 96f12ad05ee62d62474ee4cc1215f19d0a6fcdf3
Summary:
This revision generalizes the existing memoization framework to 1-ary and 2-ary
functions (namely functions of type (a -> GenHaxl u b) and (a -> b _> GenHaxl u c)).
For every support arity (currently 0, 1, and 2), a family of functions {
newMemoWithX, prepareMemoX and runMemoX } are provided. newMemo itself is
generic across all arities.
Reviewed By: simonmar
Differential Revision: D3555791
fbshipit-source-id: 010a9889d42327607c8b03a5f7a609ee0c70de49
Summary:
This revision refactors cachedComputation to only contain logic relevant to
where the request-scope memo lives; memo creation and running logic is delegated
to newMemo(with) and runMemo.
Comments in cachedComputation have been moved over to newMemo/runMemo, and a
benchmark for cachedComputation has been added to monadbench. Surprisingly,
performance might have improved, albeit very slightly.
Reviewed By: simonmar
Differential Revision: D3514791
fbshipit-source-id: b2f0627824adc79b766e4f4e28c4af957ff00a00
Summary:
This diff adds the createMemo and updateMemo helper functions, which abstract
the memoization reference management logic of cachedComputation. This separates
the work of *how* a memoized computation is created/updated, from *where* the
memo reference lives, allowing the same code to be used to manage request-scope
and feature-scope memos simultaneously.
A refactor of cachedComputation to use this abstraction is forthcoming.
Reviewed By: simonmar
Differential Revision: D3492803
fbshipit-source-id: 9dadd3860d5bec3bf776eef7c1bd610c25283729
Summary:
Memoized operations were not represented in monadbench, this diff fixes that. Three tests are included:
1. Unmemoized computation, repeated N times.
2. Memoized computation, repeated N times.
3. Memoized computation, repeated N times **under different memo keys**
Reviewed By: simonmar
Differential Revision: D3444238
fbshipit-source-id: b2df534232acd5c02f9f6aea030c55d5cc846eb0
Summary:
I'm using this to test variants of the monad. In particular, the
current monad displays O(n^2) performance with the seql version of
this benchmark. This is a well-studied problem, see for example
"Reflection without remorse: revealing a hidden sequence to speed up
monadic reflection" (van der Ploeg / Kiselyov, Haskell '14)
Test Plan:
Built it and ran it a few times
unit tests still work
Reviewed By: bnitka@fb.com
Subscribers: ldbrandy, kjm, jlengyel, memo, watashi, smarlow, akr, bnitka, jcoens
FB internal diff: D2419419
Signature: t1:2419419:1441640727:9f5f82212c829fcbf2e8c063d4dbd0db495b0ba2
