From owner-freebsd-current@FreeBSD.ORG Thu May 17 12:13:47 2012 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 21CF1106566B for ; Thu, 17 May 2012 12:13:47 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from springbank.echomania.com (andric.com [IPv6:2001:888:2003:1001:230:48ff:fe51:76b6]) by mx1.freebsd.org (Postfix) with ESMTP id AAFA18FC0C for ; Thu, 17 May 2012 12:13:46 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at springbank.echomania.com Received: from [192.168.1.6] (tensor.andric.com [87.251.56.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by springbank.echomania.com (Postfix) with ESMTPSA id E2A9AA7071; Thu, 17 May 2012 14:13:24 +0200 (CEST) Message-ID: <4FB4EB74.5040009@FreeBSD.org> Date: Thu, 17 May 2012 14:13:40 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120425 Thunderbird/13.0 MIME-Version: 1.0 To: bf1783@gmail.com References: In-Reply-To: X-Enigmail-Version: 1.5a1pre Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org, Peter Jeremy , "b. f." Subject: Re: "make delete-old" performance. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 12:13:47 -0000 On 2012-05-17 05:18, b. f. wrote:... > The slowdown is probably due - at least in part - to two factors: > > - the list of files to be checked for removal has grown substantially, > because missing entries for old knobs and new entries for new knobs > have been added; and > > - a new (and slower) method of checking was added in: > http://svnweb.FreeBSD.org/base?view=revision&revision=220255 > because the old method broke down with the size of the new lists of files. Hm, maybe it would have been better to fix make, so it can accept arbitrarily long lists, without segfaulting? There's such a thing as malloc(), and I simply don't believe any of those lists could be larger than a few hundred kilobytes.