On Wed, Jun 28, 2006 at 12:01:31PM +0200, Adam Borowski wrote: > On Wed, Jun 28, 2006 at 02:06:26AM -0700, Don Armstrong wrote: > > This has the disadvantage of not automatically using -j for every > > package and requiring maintainer buy in to see results... but > > presumably those packages where it actually makes a difference will > > adopt it just so maintainer builds don't take as long. > > Why would you restrict this just to maintainer builds? Speeding up > buildds and user builds would be a worthy goal, too. "Speeding up" buildds through uninvited make -j is certainly _not_ a worty goal, simply because you can't do that properly. SMP buildd systems currently run multiple instances of buildd at the same time, rather than expecting a package to specify make -j itself. Having three packages that specify 'make -j 4' on a multiprocessor buildd host that _already_ runs six builds in parallel is going to be devastating. While parallel builds can indeed help speed up things even on uniprocessor systems, they do this at a price; they require a _lot_ more RAM than non-parallel builds. A uniprocessor parallel build will go faster for as long as your buffercaches can keep make, the compiler, and the most often used header files in memory; as soon as those need to be swapped out, your performance will go down dramatically. Since not all machines have the same amount of RAM, it is impossible to say in a generic way when this point is going to be. In any case, I have nothing against doing parallel builds by default (at least, not as long as it can be properly disabled and regulated), but do not claim that it's a good thing "also for the buildd's", because you are sadly mistaken. -- Fun will now commence -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4
Attachment:
signature.asc
Description: Digital signature