Re: Do you want a faster gmmproc?

[Krzesimir Nowak <qdlacz gmail com>]

Forwarding message as I forgot to add gtkmm-list to CC. Sorry.


---------- Forwarded message ----------
From: Krzesimir Nowak <qdlacz gmail com>
Date: 2011/4/4
Subject: Re: Do you want a faster gmmproc?
To: Kjell Ahlstedt <kjell ahlstedt bredband net>


2011/4/4 Kjell Ahlstedt <kjell ahlstedt bredband net>:
> Present gmmproc: 13 min 25 s
> Future gmmproc:   1 min 17 s
>
> I've noticed that when you build e.g. gtkmm, the generation of .h/.cc
> files from .hg/.ccg files is a slow process. It takes more time than the
> compilation of the .h/.cc files. I suspected that gmmproc spends most
> its time reading the .defs and _docs.xml files. This is done once for
> each processed .hg file.
>
> I made a test, where I let gmmproc process all .hg/.ccg files in
> gtkmm/gtk/src (181 pairs of files). I compared the present version of
> gmmproc and a version where gmmproc is given a file containing a list of
> filenames, names of the files to process. It then reads the .defs and
> _docs.xml files only once. The result, when run on my PC, is shown at
> the beginning of this email.
>
> The total size of the .defs and _docs.xml files in gtkmm/gtk/src is
> about 4 MB, so it's perhaps not surprising that you can save time by
> reading them once instead of 181 times.
>
> Don't you think it would be a great idea to update gmmproc like this?
> If I'm not the only one to think so, I can file an enhancement bug for
> the task.
>
> My updated version of gmmproc is a quick and dirty fix, not suitable for
> distribution. And to make use of such a feature in gmmproc, the
> Makefiles must be modified. I haven't yet looked into that. gmmproc must
> be given a list of names of the files to process, instead of being
> called once for each file.
>
> Kjell
>

Yeah, reading defs and xml files everytime is the bottleneck, but
current implementation also makes it possible run several gmmprocs
concurrently (by make -j4). By converting gmmproc to be run once for
all files you'll have to provide the stamps feature, maybe concurrency
(and all whatnot it introduces probably) and handle interrupting (by
pressing ctrl+c) gracefully which was done by make. In short - it will
probably be sort of similar to doxygen itself.

Maybe this feature would be very useful when building gtkmm (which has
indeed very large defs and xml files) very often from scratch, but I
suppose it is rarely the case. In fact, I'm wondering what would be
faster in case of changing just several files (say: 3) - your future
gmmproc (I suppose it has no concurrent processing, right?) and
current gmmproc run with make -j4. :)

In fact, reading/writing this reminds me that I should be working on
gmmproc rewrite too. :)

> _______________________________________________
> gtkmm-list mailing list
> gtkmm-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtkmm-list
>