Summary: Bump to a more recent stackage-lts
Reviewed By: niteria
Differential Revision: D5257292
fbshipit-source-id: 8f3aa86c699e6b91d55998d03dab0d0440993317
Summary: This provides a way to override test file locations for other build systems.
Reviewed By: yfeldblum
Differential Revision: D5218507
fbshipit-source-id: 7087ca13afb105b727ecf3f7dfdaecd26d27ea81
Summary:
It doesn't exist in GHC 8.2 and it appears that
Data.Typeable just works.
This should fix https://github.com/facebook/Haxl/issues/70.
Differential Revision: D5086644
fbshipit-source-id: e3e48ea7d603bbdf4fd78b4acd5125761ce799b2
Summary: text prior to 1.2.1.0 doesn't work because we need the Binary instance
Reviewed By: niteria
Differential Revision: D5027630
fbshipit-source-id: d6eeefb40a19ae2c0aaccaad868dc42ed4976ea5
Summary: Adds a simple `stack` file using the latest version of stackage.
Reviewed By: watashi
Differential Revision: D4843970
fbshipit-source-id: 938a16de769210661064157084f5eac42c7c0494
Summary:
- `binary-0.9` is accidental major jump and is now deprecated, I'm not sure what's best to do, cabal solver should pick `-0.8.x.y.` version
- `HUnit` and `time` changes do not affect use in haxl.
Closes https://github.com/facebook/Haxl/pull/68
Differential Revision: D4843906
Pulled By: JonCoens
fbshipit-source-id: b97c78e644a170745d7a29aab5c137e86f7018be
Summary:
These two operators are subtly non-deterministic, but can potentially
improve performance significantly in cases where
* We don't want to use .|| because it's too sequential
* We don't want to use || because it forces us to do wasted work
(and equivalently for &&).
The implementation is a bit subtle, see Note [tricky pOr/pAnd]
Reviewed By: xich
Differential Revision: D4611809
fbshipit-source-id: 832ace29dfc44e48c14cc5d4f52a0114ee326c92
Summary:
I didn't look into this too deeply but I'm guessing it was because the
constant expression had been lifted out, so I made it not a constant
expression.
Reviewed By: JonCoens
Differential Revision: D4521430
fbshipit-source-id: 687075d8486b38743b3bd8b9a9f26aa198b2d258
Summary:
If this goes ok, can we have a release?
Closes https://github.com/facebook/Haxl/pull/66
Reviewed By: simonmar
Differential Revision: D4409114
Pulled By: niteria
fbshipit-source-id: 6d6e88f1cf7b9ae2d851eaa86966f2eb417b4d7e
Summary:
Alternatively we could change dependency to `aeson-compat`, which has less major version bumps (because it has smaller public API surface, yet one have to be careful .e.g. not to rely on instance implementations).
Closes https://github.com/facebook/Haxl/pull/64
Differential Revision: D4385525
Pulled By: xich
fbshipit-source-id: 72246e0f9144728e618de7bfcf983531bd3d281a
Summary:
Include request in the uninitialized data source error so we will
know which request is not in cache or triggering this problem.
This will increase the size of error message, but in production
this should not happen as we should sanitize data source is
initizlied correctly.
Reviewed By: codemiller
Differential Revision: D4342674
fbshipit-source-id: ec3506285806e749dccade5ba5eb8cfdb25a5671
Summary: `GenHaxl` having an `NFData` instance is apparently a lie. Remove this functionality
Reviewed By: simonmar
Differential Revision: D3967290
fbshipit-source-id: 1da91dcd6470de0f911e8a29b86c4aa5d6c7301f
Summary: Some of the test files were not listed in haxl.cabal
Reviewed By: kuk0
Differential Revision: D3951346
fbshipit-source-id: 8e6677a728acde3713c618a6383b2de510b1ac86
Summary: Having an NFData instance allows forcing calls that return a Haxl computation to run.
Reviewed By: xich
Differential Revision: D3906781
fbshipit-source-id: e49448152695383031af6d315a20dbcd1c10720c
Summary:
Labels which throw Haxl exceptions are recorded, but pure exceptions bubble up
and labels are lost. This test demonstrates this.
Reviewed By: simonmar
Differential Revision: D3672479
fbshipit-source-id: fab10878e7eb067e0c65bcf401d75604c333007f
Summary: Prior to GHC 7.10, <$> was not in the prelude, so requires an explicit import.
Reviewed By: watashi
Differential Revision: D3656379
fbshipit-source-id: 43925bc9c483ee712b04976d6fa6cb6b9d9b998e
Summary:
The 7.8 build keeps breaking, but no one notices until someone opens an issue.
With the travis badge, breakage will at least be visible from the github
landing page for Haxl repo.
Reviewed By: zilberstein
Differential Revision: D3656468
fbshipit-source-id: 5537ab78b9dd44a5a3f07e7e3db7f73ec959f096
Summary: Expose MiddleException because the `eName` function is useful.
Reviewed By: watashi
Differential Revision: D3635507
fbshipit-source-id: bec3fac0b4f7c009c57d14857d46576ffc5ab826
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 collects the stack traces of `dataFetch` calls, when `reportLevel` >= 5 and profiling is on. Zero overhead for non-profiled code.
Reviewed By: niteria
Differential Revision: D2535947
fbshipit-source-id: fd43c20edd5455bd5e41113059fc69206b998e44
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: Track and report allocation usage for data sources and rounds
Reviewed By: simonmar
Differential Revision: D3488169
fbshipit-source-id: 39c853ec89881e9f7d8d32b1a8d0a878c847a33e
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: Integrate counts of memoized computation access into the profiling framework. Every call to `cachedComputation` logs one hit, including the first one.
Reviewed By: simonmar
Differential Revision: D3430491
fbshipit-source-id: a799c0e603c7bc94813da9801d7f4931a011131d
Summary:
Add a :profile command to haxlsh to view lightweight profiling data.
Has optional flags to sort output on a given column, or filter rows by name
with a regex.
Useful for iterating while trying to squash allocation issues.
Differential Revision: D3429989
fbshipit-source-id: 3631afbac6f7a8580b1c46fae8039bacaa996ab3
Summary: Some tests were failing, but we ignored the test failures by not checking the return value from the test runner. This patch fixes both the test runner and the tests.
Reviewed By: watashi
Differential Revision: D3379609
fbshipit-source-id: 0a1278879faa5beb0f9779ddfaa622cdbf05a73f
Summary:
This diff does two things:
1. Claws back performance lost to lightweight profiling, and then some.
Haxl monad with lightweight profiling is now faster than it was before
lightweight profiling was added.
par1 and tree are ~20% faster.
seqr is ~10% faster.
par2 and seql are unchanged.
2. Eliminate redundant constraints on some exported functions.
Wherever types on exported functions changed, they became less
constrained with no loss of functionality. Notably, the *WithShow
functions no longer require pointless Show constraints.
Now the gory details:
Monadbench on master (before lightweight profiling):
par1
10000 reqs: 0.01s
100000 reqs: 0.11s
1000000 reqs: 1.10s
par2
10000 reqs: 0.02s
100000 reqs: 0.41s
500000 reqs: 2.02s
seql
10000 reqs: 0.04s
100000 reqs: 0.50s
500000 reqs: 2.65s
seqr
200000 reqs: 0.02s
2000000 reqs: 0.19s
20000000 reqs: 1.92s
tree
17 reqs: 0.48s
18 reqs: 0.99s
19 reqs: 2.04s
After D3316018, par1 and tree got faster (surprise win), but par2 got worse, and seql got much worse:
par1
10000 reqs: 0.01s
100000 reqs: 0.08s
1000000 reqs: 0.91s
par2
10000 reqs: 0.03s
100000 reqs: 0.42s
500000 reqs: 2.29s
seql
10000 reqs: 0.04s
100000 reqs: 0.61s
500000 reqs: 3.89s
seqr
200000 reqs: 0.02s
2000000 reqs: 0.19s
20000000 reqs: 1.83s
tree
17 reqs: 0.39s
18 reqs: 0.77s
19 reqs: 1.58s
Looked at the core (-ddump-prep) for Monad module.
Main observation is that GHC is really bad at optimizing the 'Request r a' constraint because it is a tuple.
To see why:
f :: Request r a => ...
f = ... g ... h ...
g :: Show (r a) => ...
h :: Request r a => ...
GHC will end up with something like:
f $dRequest =
let $dShow = case $dRequest of ... in
let $dEq = case $dRequest of ... in
... etc for Typeable, Hashable, and the other Show ...
let g' = g $dShow ... in
let req_tup = ($dShow, $dEq, ... etc ...) in
h req_tup ...
That is, it unboxes each of the underlying dictionaries lazily, even though it only needs the single Show dictionary.
It then reboxes them all in order to call 'h', meaning none of the unboxed ones are dead code.
I couldn't figure out how to get it to do the sane thing (unbox the one it needs and pass the original dictionary onwards).
We should investigate improving the optimizer.
To avoid the problem, I tightened up the constraints in several places to be only what is necessary (instead of all of Request).
Notably:
Removed Request constraint from ShowReq, as it was completely unnecessary.
All the *WithShow variants do not take Show constraints at all. Doing so seemed to violate their purpose.
The crucial *WithInsert functions only take the bare constraints they need, avoiding the reboxing.
Since *WithInsert are used by *WithShow, I had to explicitly pass a show function in places.
See Note [showFn] for an explanation.
This gave us back quite a bit on seql, and a bit on seqr:
par1
10000 reqs: 0.01s
100000 reqs: 0.08s
1000000 reqs: 0.90s
par2
10000 reqs: 0.02s
100000 reqs: 0.36s
500000 reqs: 2.18s
seql
10000 reqs: 0.04s
100000 reqs: 0.55s
500000 reqs: 3.00s
seqr
200000 reqs: 0.02s
2000000 reqs: 0.18s
20000000 reqs: 1.73s
tree
17 reqs: 0.39s
18 reqs: 0.79s
19 reqs: 1.54s
Finally, addProfileFetch was getting inlined into dataFetchWithInsert.
This caused some let-bound stuff to float out and get allocated before the flag test.
Adding a NOINLINE prevented this, getting about 10% speedup on par2 and seql.
Doing the constraint work above enabled this, because otherwise the call to
addProfileFetches was creating the reboxing issue where it didn't exist before.
par1
10000 reqs: 0.01s
100000 reqs: 0.08s
1000000 reqs: 0.89s
par2
10000 reqs: 0.02s
100000 reqs: 0.35s
500000 reqs: 1.98s
seql
10000 reqs: 0.04s
100000 reqs: 0.53s
500000 reqs: 2.72s
seqr
200000 reqs: 0.02s
2000000 reqs: 0.17s
20000000 reqs: 1.67s
tree
17 reqs: 0.39s
18 reqs: 0.82s
19 reqs: 1.65s
Reviewed By: simonmar
Differential Revision: D3378141
fbshipit-source-id: 4b9dbe0c347f924805a7ed4c526c4e7c9aeef077
