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 _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
