Re: Do you want a faster gmmproc?

[Kjell Ahlstedt <kjell ahlstedt bredband net>]

I have filed bug 646820 gmmproc: Increase speed by processing many files
in one invocation. https://bugzilla.gnome.org/show_bug.cgi?id=646820

mån 2011-04-04 klockan 23:16 +0200 skrev Krzesimir Nowak:

> 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.

Ok, I don't do it every day, not even every week, but when I update my
local copy of gtkmm with 'jhbuild build' it often regenerates and
recompiles all or most of glibmm and gtkmm (as well as glib and gtk+,
which is also time-consuming).

> 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. :)

Right, my modified gmmproc has no concurrency. I have an old-fashioned
PC with a single-core processor, and I didn't even think of concurrency.
If you update only 3 files, I guess it doesn't matter much which
alternative you choose. Even the present gmmproc without concurrent
processing is fast enough.

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

Krzesimir, you have mentioned at
https://bugzilla.gnome.org/show_bug.cgi?id=641165#c3 that you plan a
major rewrite of gmmproc. Do my ideas for a faster gmmproc in any way
clash with your plans? I don't want to make your job more difficult.
Would it be better if you rewrite gmmproc first, and only afterwards we
add new features? Such as this one, and the one I've proposed in bug
86864 "enums should be inside classes"
(https://bugzilla.gnome.org/show_bug.cgi?id=86864).

Kjell