I couldn't quite figure out how to make a type-dependent CAF in the class
instances, as your paper suggests, so I made my CAF at the top-level
instead
instance Domain a b where
domain = \_ -> res
where res = ... the computed domain ...
class Domain a b where
domain :: (a,b) -> IntSet
That should work.
Yes, that is roughly what I tried but, unfortunately, it is very
fragile against (lack of) optimisations, and I haven't yet figured
out what small variation prevents it from working in my real
code, when it works in my slightly simplified tests..
I think I've figured out what is going on: this technique simply
doesn't work as well as we might hope it would! Here's why:
While you ignore the explicit parameter, in practice there's an
implicit dictionary parameter that is actually being used in res
(Data/Typeable). At first sight, that might sound okay -we
want a caf per type after all- but what happens is that we
get *a caf per dictionary parameter* instead.
So, if several calls share the same dictionary parameter, they
also get the same caf, resulting in the memoization speedup
we want (if the substructure types are recomputed every time,
that isn't going to be faster than doing the travesals we want to
avoid). If, however, the calls are unrelated, they get separate
cafs, leading to recomputation of the substructure maps and
loss of performance.
Try this variation of the Paradise benchmark data:
genCom :: Company
genCom = C $ take 100000 $ cycle
[D "Research" laemmel [PU joost, PU marlow],
D "Strategy" blair []]
Then,
import Data.Generics.PlateData
uni_bill x = sum [ s | S s <- universeBi x]
turns out to be rather slower than expected, and a lot slower
than using a single top-level caf with a Map from TypeRefKeys
to IntSets of TypeRefKeys (listing for each type of interest its
substructure types).
Am I on the right track here?
Claus
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
