[C2hs] Profiling c2hs

[Duncan Coutts]

On Sat, 2004-05-15 at 09:32, Manuel M T Chakravarty wrote:
> I had a closer look now and we need a bit of cooperation from the parser
> library; so, I extended Parsers.execParser to take a token converter as
> an additional argument.  In the C declaration parser, this token
> converter changes from declaration to declaration, as more and more
> typedef'd names are collected.  (They are collected in a Set now.)
> 
> I attach a patch that modifies base/syntax/Parsers.hs and
> c2hs/c/CParser.hs accordingly.  As the patched functions didn't change
> for quite a while, this patch should be quite independent of the version
> of c2hs that you have got.  Could you please profile the patched parser
> again and see whether its space and runtime behaviour changed?

Here's the stats:

Original before patch:

time (non-profiling, -O)   : 1m9
time (profiling)           : user    2m51
total alloc                : 3.4 G
time spent in
   parseCExtDeclList       : 72%
   morphTypeNames          : 54%
alloc spent in
   parseCExtDeclList       : 70%
   morphTypeNames          : 63%


With Manuel's patch:

time (non-profiling, -O)   : user    0m41
time (profiling)           : user    1m35
total alloc                : 1.4 G
time spent in
   parseCExtDeclList       : 43%
   morphTypeNames          : 7%
alloc spent in
   parseCExtDeclList       : 26%
   morphTypeNames          : 8%

So that's a significant change. Cheers Manuel.

I've rebuilt gtk2hs with this and it doesn't seem to break anything.
If you're happy with this patch, I'll apply it in our c2hs fork.

BTW I was wondering what the --keep option does, I was hoping it would
cache the information extracted from the C header files, but I guess
not. Would this be very difficult? As you know, gtk2hs has a fork of
c2hs with a patch to accept multiple .chs files, which saves time by
saving the header information in memory. It would probably be almost as
quick if this information was cached in a file. This would have the
advantage that people wouldn't need to change their build systems to
process multiple .chs files in one go (as gtk2hs has done) which is
rather a pain. If we could do this, it would get us much closer to
getting gtk2hs back to using the mainline version of c2hs. (The only
other change as I recall is a quick fix to make ForeignPtrs do what we
want. I understand you're weren't happy with it as a long-term solution)

Duncan