[Haskell-cafe] parsec2 vs. parsec3... again

[Evan Laforge]

> Now attoparsec-text is more than twice faster, allocates even less
> memory and the total memory figures seem right.
>
> Bottom line: I think this benchmark doesn't really represent the kind
> of workload your parser has.  Can you reproduce these results on your
> system?

I spent quite a bit of time trying to reduce this down to a minimal
reproduction and getting confusing results.  Then I found out that
compiling with profiling enabled makes attoparsec slow and parsec
fast.  When I compile without any profiling, here's what I get, in CPU
time:

parsec run 1000000 - time: 1.22s -
atto bs run 1000000 - time: 0.38s -
atto text run 1000000 - time: 0.78s -

This looks more like I expect it to.  I don't understand the parsec
thing... one of the first things I did was recompile and reinstall
parsec2, making sure to pass -p to configure, and verify that there is
a /usr/local/lib/parsec-2.1.0.1/ghc-6.12.3/libHSparsec-2.1.0.1_p.a.
However, on closer inspection, I believe I've found the culprit.
Compiling with 'build -v' for attoparsec reveals a ghc cmdline line:
'-prof -hisuf p_hi -osuf p_o -auto-all'.  Compiling parsec has: '-prof
-hisuf p_hi -osuf p_o'.  And indeed, attoparsec cabal has
'ghc-prof-options: -auto-all', which parsec's cabal does not.  And in
fact, parsec3 also has this -auto-all, which both explains why the
profile is full of internal functions and why parsec3 was so much
slower than parsec2.

I'm glad to have finally tracked this down, but unhappy that I spent
so much time on it.  It seems like a trap waiting to be sprung if
various libraries are compiled with their individually specified
flags, which have major effects on performance.  Maybe I should have
noticed, but it seems pretty subtle to me.  GHC will refuse to compile
non-profiling libs against a profiling build, but doesn't go down to
the level of flags.

I think my short term solution is going to be remove -auto-all from
attoparsec's cabal---I'm not profiling attoparsec and so I don't want
my entire profile output to be internal attoparsec functions.  But
presumably the flag was added there for a reason, so maybe there are
people who really want that.  Is there a better solution?  GHC warns
when linking a profiling lib compiled with different profiling flags?
A separate .p_auto-all_o suffix?  Removal of ghc-prof-options from
cabal?  A consensus to standardize on a set of flags?


BTW, yes my situation is a little different from your test.  It's lots
and lots of little expressions for a simple language in an in-memory
structure that get parsed individually.  So I don't care about file
reading speed, but I do care about parser startup overhead, since it's
lots and lots of little parses.  The numbers above are how long it
takes to parse "2.34" 1m times.