From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8940 invoked by alias); 12 Dec 2012 19:29:48 -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: 30873 Received: (qmail 4541 invoked from network); 12 Dec 2012 19:29:46 -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: <121212112913.ZM28328@torch.brasslantern.com> Date: Wed, 12 Dec 2012 11:29:13 -0800 In-reply-to: <20121212095628.66cb27f3@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: It's time for 5.0.1" (Dec 12, 9:56am) References: <20121206194404.698168c9@pws-pc.ntlworld.com> <121208115416.ZM27266@torch.brasslantern.com> <20121209191005.27a7ba33@pws-pc.ntlworld.com> <121212001411.ZM27450@torch.brasslantern.com> <20121212095628.66cb27f3@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: It's time for 5.0.1 MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 12, 9:56am, Peter Stephenson wrote: } } On Wed, 12 Dec 2012 00:14:11 -0800 } Bart Schaefer wrote: } > The problem with this is that the better zhalloc() is at filling up } > the Heap arenas, the harder freeheap() has to work -- because it ends } > up managing a Heapstack for each of a bunch of useless [that is, } > full] Heap arenas. At that point it'd be much better if it just } > pushed the entire heaps list and started over from scratch. } } One point about the above is that if we keep the heap size small, 16384 } instead of ~ 10 times as much Regarding that ... there are some comments in zsh.h that make it appear we should stick with multiples of 8, so 131072 or 262144 if we were in fact to make it "about 10" times bigger. } it's much less wasteful to forget about } heapstacks altogether and simply mark the current heap and start a new } one when you push. Then you just have the one linked list and } everything stays linear. Well, there are still two linked lists: the currently growing heap and the stack of pushed heaps. I think we can do away with the Heapstack struct and use the heapstack pointer in the Heap struct to manage the pushed heaps. } I think wasting something of order 16 kB each } time we push (and getting it back when we pop) is probably neither here } nor there these days. Well ... in a pathological case (lots of allocations of 8k+1 bytes) you might be wasting as much space as was already in use. But you could construct a similar pathological case for the current algorithm, so I don't think it's worth solving right now. } I'm not 100% sure what's going on with switch_heaps(), but you might } hope it was agnostic about the underlying heap implementation. I briefly considered NEWHEAP/OLDHEAP or SWITCHHEAPS/SWITCHBACKHEAPS as a stand-in for pushheap/popheap in selected contexts, but concluded that I don't understand well enough to initialize them ... nor do I recall why the completion system is using them, except that it seems to have something to do with completion-specific special parameters. But I don't think they fiddle with how push/free/pop work underneath.