From owner-p4-projects@FreeBSD.ORG Thu Jan 8 19:22:59 2009 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 99CB41065673; Thu, 8 Jan 2009 19:22:59 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 587AA1065670 for ; Thu, 8 Jan 2009 19:22:59 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id E2BC48FC18 for ; Thu, 8 Jan 2009 19:22:58 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=VWUNZqetDUwA:10 a=nklthdr5v5AUSfVrlghuJA==:17 a=xvzNxC0hOXTdhLn-BQsA:9 a=qlKYuZpUoz9lQtNOct_9aqe-Hp8A:4 a=SV7veod9ZcQA:10 a=LY0hPdMaydYA:10 Received: from [62.113.132.62] (account mc467741@c2i.net [62.113.132.62] verified) by mailfe13.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 787402726; Thu, 08 Jan 2009 20:22:57 +0100 From: Hans Petter Selasky To: Ed Schouten Date: Thu, 8 Jan 2009 20:25:19 +0100 User-Agent: KMail/1.9.7 References: <200901071009.n07A9jrs056953@repoman.freebsd.org> <200901082010.33577.hselasky@freebsd.org> <20090108191335.GT45775@hoeg.nl> In-Reply-To: <20090108191335.GT45775@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901082025.20711.hselasky@freebsd.org> Cc: Remko Lodder , perforce@freebsd.org, "M. Warner Losh" Subject: Re: PERFORCE change 155748 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Jan 2009 19:23:00 -0000 On Thursday 08 January 2009, Ed Schouten wrote: > * Hans Petter Selasky wrote: > > Everything is possible. > > > > How would you explain the benefit of the +19Mbyte of data resulting from > > this autogeneration when building the modules ? > > I think we always had a preference to generate stuff on demand. It's a > lot easier to maintain. Hi, I can understand that, but how about only generating the file once when you know it will be needed 60 times in a row? This also applies to other autogenerated files. It would speed up the module build alot I think. cd src/sys/modules/usb2/serial_3g make all clean time make all 0:01.58 rm u3g2.o time make all 0:00.96 You see it is around 50% slower to build a module which needs to generate N header files first, than if those header files were cached somewhere! Multiply the time you save by 60, and we are talking about a significant amount of time! --HPS