From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6748 invoked by alias); 20 Nov 2012 17:45:02 -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: 30808 Received: (qmail 5568 invoked from network); 20 Nov 2012 17:45:01 -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: <121120094443.ZM5584@torch.brasslantern.com> Date: Tue, 20 Nov 2012 09:44:42 -0800 In-reply-to: <121120090300.ZM5552@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: argv subscript range uses too many memory" (Nov 20, 9:03am) 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> 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 [Moved to zsh-workers; Han Pingtian Cc'd in case he's only on -users] On Nov 20, 9:03am, Bart Schaefer wrote: } } Unfortunately as far as I can tell these two issues (the speed problem } in last year's "the source of slow large for loops" thread and the space } problem in this thread) are directly in conflict with one another. The } speed problem requires that the heap not be fully garbage collected on } every loop pass, but the space problem requires that it be collected at } some point before the loop is done. } } Maybe there's a hybrid where freeheap() can examine the difference in } position (fheaps - heaps) and do a full garbage collect only when the } heap has become "too full". On a moment's reflection that doesn't work directly because both heaps and fheaps are pointers into a linked list, so they can't be differenced that easily. Theoretically fheaps must always either be NULL or have a value greater than or equal to heaps, but beyond that nothing forces heap blocks to be in sequential pointer order, they could be returned by malloc() in any arbritrary order. So what we need is a fast way to estimate how much uncollected garbage is in the heap -- or, conversely, a fast way to estimate how close we are to running out of memory -- so that garbage collection can be put off until it's necessary. Or, as I said before, find a scope in which to pushheap/popheap ... -- Barton E. Schaefer