From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1974 invoked by alias); 20 Nov 2012 23:23:20 -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: 30812 Received: (qmail 25082 invoked from network); 20 Nov 2012 23:23:17 -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: <121120152257.ZM5937@torch.brasslantern.com> Date: Tue, 20 Nov 2012 15:22:57 -0800 In-reply-to: <20121120210552.19eb87a9@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: argv subscript range uses too many memory" (Nov 20, 9:05pm) 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> <20121120210552.19eb87a9@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: argv subscript range uses too many memory Cc: Han Pingtian MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Nov 20, 9:05pm, Peter Stephenson wrote: } } Instead of optimising freeheap for the case where the are lots of } heaps, could we just increase HEAPSIZE? It's only 16384 (minus a } header), which seems pretty small to me. Note that HEAPSIZE is only the lower limit on the size of an arena. The actual size will depend on the largest contiguous chunk requested of zhalloc(). Which is a bit strange because all calls to zfree() use the HEAPSIZE or HEAPFREE constants instead of h->size or perhaps ARENA_SIZEOF(h). It must really not matter to zfree(). In any case workers/29175 isn't really optimizing just for a lot of heaps or even for a lot of allocated memory; it's optimizing for a lot of calls to freeheap(), most of which don't really have anything useful to do. It's just that in Han Pingtian's example there IS something useful to do, but the optimization skips doing it because fheap has been advanced [by zhalloc()] to point only at the most recently allocated block. If you think of the heaps linked-list as proceeding left to right, then with 29175 freeheap assumes fheap points somwhere in the middle of the list, but zhalloc tends to move it too far to the right. It remains to be seen whether 30809 moves it too far back to the left (that is, effectively reverses 29175). Or ... I may have completely misinterpreted how freeheap is supposed to do its work, and there's an entirely different optimization that should be done in place of 29175.