Forwarding message as I forgot to add gtkmm-list to CC. Sorry.
---------- Forwarded message ---------- From: Krzesimir Nowak <[email protected]> Date: 2011/4/4 Subject: Re: Do you want a faster gmmproc? To: Kjell Ahlstedt <[email protected]> 2011/4/4 Kjell Ahlstedt <[email protected]>: > 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gtkmm-list > _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
