From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23238 invoked from network); 8 May 2004 14:03:04 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 8 May 2004 14:03:04 -0000 Received: (qmail 19802 invoked from network); 8 May 2004 14:02:45 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 8 May 2004 14:02:45 -0000 Received: (qmail 4649 invoked by alias); 8 May 2004 14:02:40 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 19895 Received: (qmail 4638 invoked from network); 8 May 2004 14:02:40 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 8 May 2004 14:02:37 -0000 Received: (qmail 19453 invoked from network); 8 May 2004 14:02:36 -0000 Received: from acolyte.scowler.net (216.254.112.45) by a.mx.sunsite.dk with SMTP; 8 May 2004 14:02:34 -0000 Received: by acolyte.scowler.net (Postfix, from userid 1000) id 517E57004A; Sat, 8 May 2004 10:02:07 -0400 (EDT) Date: Sat, 8 May 2004 10:02:07 -0400 From: Clint Adams To: Bart Schaefer Cc: 245678-submitter@bugs.debian.org, zsh-workers@sunsite.dk Subject: Re: Bug#245678: zsh: built-in rm -rf fills up the memory Message-ID: <20040508140207.GA25045@scowler.net> References: <20040424162150.GA4210@ay.vinc17.org> <20040425013647.GA28395@scowler.net> <1040425204530.ZM25792@candle.brasslantern.com> <20040425211239.GA5011@scowler.net> <1040426171013.ZM26825@candle.brasslantern.com> <20040508043530.GA21396@scowler.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040508043530.GA21396@scowler.net> User-Agent: Mutt/1.5.5.1+cvs20040105i X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=-0.0 required=6.0 tests=BAYES_44 autolearn=no version=2.63 X-Spam-Hits: -0.0 > I think I've found the problem. Here's an excerpt from an strace of > the zsh/files rm -rf going wild. There are 55 or 56 such calls to mmap > for every length value. Thus it appears that zsh is allocating > considerably more memory than it needs. More on this: recursivecmd_dorec() calls hrealloc() for each target file, incrementing size accordingly. hrealloc() rounds the new length up to the nearest page boundary, and mmaps a new Heap for each file. So, for example, if you have a directory with one hundred files with 9-byte filenames, zsh might allocate one hundred 4096-byte areas. If you have several thousand files with 70- to 80-byte filenames, zsh might allocate over 50 4096-byte areas, over 50 8192-byte areas, and so on. Now, should this be fixed by making hrealloc() smarter or recursivecmd_dorec() more efficient?