From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21633 invoked by alias); 25 Nov 2012 19:03:51 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30824 Received: (qmail 20453 invoked from network); 25 Nov 2012 19:03:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <121125110336.ZM3405@torch.brasslantern.com> Date: Sun, 25 Nov 2012 11:03:36 -0800 In-reply-to: <20121125081145.GC2576@localhost.localdomain> Comments: In reply to Han Pingtian "Re: argv subscript range uses too many memory" (Nov 25, 4:11pm) References: <20121108084001.GA7594@localhost.localdomain> <20121108100226.575b0788@pwslap01u.europe.root.pri> <20121110105811.GA7136@localhost.localdomain> <121110065709.ZM4781@torch.brasslantern.com> <20121120130457.GD2500@localhost.localdomain> <121120090300.ZM5552@torch.brasslantern.com> <121120094443.ZM5584@torch.brasslantern.com> <121120102415.ZM5635@torch.brasslantern.com> <20121122092847.GA2576@localhost.localdomain> <121122102927.ZM8049@torch.brasslantern.com> <20121125081145.GC2576@localhost.localdomain> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: argv subscript range uses too many memory MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 25, 4:11pm, Han Pingtian wrote: } Subject: Re: argv subscript range uses too many memory } } On Thu, Nov 22, 2012 at 10:29:27AM -0800, Bart Schaefer wrote: } > } > If you would not mind, try removing both that patch and the one you } > previously removed for 29175, but increase HEAPSIZE } } I have tried this. It works just fine. Both problems lools like has been } fixed. Do you think it is the right solution? It's a large step in the right direction. The questions remaining are: What is the right value for HEAPSIZE? Mmultiplying it by 10 is was just a quick way to test; it might be better to multiply by 8 or 16 to keep a size that's a power of 2 for efficient byte alignment of arena blocks. It depends on the underlying malloc implementation. Has this really addressed the problem from 29175? Larger blocks will mean it takes longer for the arena list to grow, but a loop that uses enough memory can still become pathologically slow.