Open dredozubov opened 6 years ago
I've encountered this too. Compilation time for large records makes this library unusable :(
Maybe the slowdown has to do something with SuperRecord.SortInsert
?
No, the slowdown also exists w/o the SortInsert :-(
When disabling optimization stack build --fast
, a record of 20 elements takes about 8 seconds to compile on my laptop, as opposed to ca. 100s when fully optimizing.
I am currently writing a similar library, and I benchmarked against superrecord (just the compile time) The file that gets compiled is here (just creates a record with 40 entries): https://gist.github.com/jvanbruegge/e2297f8e57e783f845f56f0627afc7ba Results on my laptop for superrecord:
stack build 1054,20s user 15,07s system 98% cpu 18:06,09 total
and my library:
stack build 37,06s user 2,83s system 88% cpu 45,272 total
I am not sure where this difference comes from, my rows are also sorted and the runtime representation of records is also a SmallArray#
I figured that the order of labels was the best case for my RowAppend type family as it would be a O(1)
cons each time (making it O(n)
). But even after reversing order of labels which is the O(n²)
worst case it was still way faster:
stack build 123,89s user 9,02s system 95% cpu 2:19,09 total
Compilation performance is evident on records of bigger size, just one record of 30-50 fields is able to make GHC swap. There's a branch and a script I've used to dig more info on this: https://github.com/dredozubov/superrecord/tree/ghc-test-case https://github.com/dredozubov/superrecord/blob/ghc-test-case/build-all.sh
I did a small investigation on this. Tried it with GHC 8.0.2 and 8.2.1(it can be done with
allow-newer
). Building it with GHC HEAD is not currently possible due to the broken dependencies. Here we go: https://github.com/dredozubov/superrecord/blob/ghc-test-case/test/Spec.hs.in#L451 construction of a record with 35 fields take up to 2 minutesRecCopy
produces a huge amount of coercions: https://gist.github.com/dredozubov/6ce629d1ec16ac32e9a987ffefda2a2a There's a lot of rewriting going on(a lot of heavy inlining in the library). Here are some core2core dumps with their respective size:These dumps are too big to add as gists, so I've uploaded this tar archive instead: https://www.dropbox.com/s/pql4qgm5lplbe38/dump-35.tar.gz?dl=0
It's possible to rebuild all of this with
nix-shell -p python3 --run "ghc=/Users/dr/.stack/programs/x86_64-osx/ghc-8.0.2/bin/ghc m=25 n=35 ./build-all.sh -package-db ~/.stack/snapshots/x86_64-osx/lts-8.20/8.0.2/pkgdb/"
, skipping the nix-shell bit if you have python3 installed on your system and substituting theghc
variable andpackage-db
with correct values for you system.m
andn
variables mean it'll rebuild the module 10 with records of length 25 to 35.