On Monday 24 March 2003 2:50 pm, Gerard Vermeulen wrote: > On Mon, Mar 24, 2003 at 03:09:17PM +0100, Hans-Peter Jansen wrote: > > On Monday 24 March 2003 13:05, Phil Thompson wrote: > > > On Monday 24 March 2003 11:53 am, Hans-Peter Jansen wrote: > > > > Hi Phil, > > > > > > > > in order to saturate multiple CPUs on SMP systems, I've created the > > > > attached patch. > > > > > > > > The problem is, that the qt module consists of 228 single modules, > > > > and build of its concatenated module outlasts all others by a few > > > > minutes here. > > > > > > > > With it applied, I was able to reduce the rpm build time from 16:15 > > > > to 13.30 on my Dual P3/1000. > > > > > > > > Since it is created on top of my former patch, it will apply with > > > > offsets, if applied first. > > > > > > But doesn't this slow it down for everybody with a UP machine? > > > > > > Phil > > > > Well, yes, I have to admit. But the performance hit is less then the > > improvement, aka 19:53 -> 21:29 UP, AMD 2000+ (~8%), 16:15 -> 13:30 > > (~20%). > > > > Would you accept a combined cleaned up patch with different lower case > > options for this and the lib stuff? > > If you are proposing this, why don't you generalize and code something like > the -j switch (parallel build switch) for make. > > In this case there is no penalty for UP machines (by default one single > huge.cpp), and the guys with 4 processors will feel happy, too :-)
Yes - I'd be happy with this. It also helps those compilers (aka MSVC) that choke on such a large C++ file but would probably handle... python build.py -c -j 10 Phil _______________________________________________ PyKDE mailing list [EMAIL PROTECTED] http://mats.gmd.de/mailman/listinfo/pykde
