Andrew Coppin
I'm more worried about what happens in less trivial examples. [Let's face it, who wants to compute the sum of the numbers from 1 to N?]
Inspired by Don's blog post, and coincidentally working on a program where profiling points to one particular, short function as responsible for 60% of the work, I thought this would be a good time to look into core and reveal the deep secrets of my code. This is the function:
mkAnn :: ByteString -> Annotation mkAnn = pick . B.words where pick (_db:up:rest) = pick' up $ getGo rest pick' up' (go:_:ev:_) = Ann (B.copy up') (read $ B.unpack go) (read $ B.unpack ev) getGo = dropWhile (not . B.isPrefixOf (pack "GO:"))
A bit clunky, but simple enough: given a line of input, break into words, pick word number two, the word starting with "GO:" and the second-to-next word. Here are the data types involved:
data Annotation = Ann !UniProtAcc !GoTerm !EvidenceCode deriving (Show) newtype GoTerm = GO Int deriving (Eq,Ord) type UniProtAcc = ByteString data EvidenceCode = ... -- many nullary constructors
Unfortunately, this results in no less than four pages of core, with tons of less intelligible identfiers and nested cases and whatnot... any idea why this would be so slow? -k -- If I haven't seen further, it is by standing in the footprints of giants