From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21442 invoked by alias); 11 Oct 2015 17:31:25 -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: 36836 Received: (qmail 19650 invoked from network); 11 Oct 2015 17:31:25 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=EJB22kL9o+iZc1Bb2ttN7B6GHkHei3GmO/oC3zKSmFo=; b=bO2KlFtZxt3Pj62+FE36rvxDrf+UlKWXb3sEzFZHuMVoKab4Mt35Pg2Er7xY900LEG SyOCBzRFY02uaUbgq9qeMLnn+x5aIJ2d8YeVWghgHU666WdRJIyINwykoNhpsFO8RlyJ 36fQCu0ydLMYaJbMBDMdHYeHysipIOX2Bti/QqX426LcMUVoGBUeKDr0mKnWWi/OabAk RARoNxd66v03C0jktYD2PO6KVwHJKdBivppkrGe8+fvhD0dVUYZNcDPE1ezQ1h+jRWu1 /Jl5B8JbaDEBg3K6lfplZwdQOmSwG74xtsyRQPfhIeBjQCE9vLpCa7fzrCIzu8Ozg4gn 5RhQ== X-Gm-Message-State: ALoCoQnXzhUzn17yBiA5RTL3WSXms/7OBWxoonZtbezSC1TRoF8AD8ZAepaae70pE375YXOVy9DF X-Received: by 10.202.91.2 with SMTP id p2mr12121800oib.41.1444584683170; Sun, 11 Oct 2015 10:31:23 -0700 (PDT) From: Bart Schaefer Message-Id: <151011103121.ZM8814@torch.brasslantern.com> Date: Sun, 11 Oct 2015 10:31:21 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: Slowdown around 5.0.5-dev-0" (Oct 11, 6:48pm) References: <151010105849.ZM10144@torch.brasslantern.com> <151010170623.ZM16166@torch.brasslantern.com> <151010232045.ZM12931@torch.brasslantern.com> <151011091757.ZM27755@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Slowdown around 5.0.5-dev-0 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Oct 11, 6:48pm, Sebastian Gniazdowski wrote: } } It's now much faster, zprof time 11851 vs 3433. That's still strongly } lagging behavior. One other trait is that it slows down after a while. The whole algorithm is designed to maximally fill the allocated space and thereby minimize the memory footprint, not to maximize speed. So the more often you grow/free the heap, the more time it spends looking for unused space in the existing arenas. Besides zprof, it would be interesting to see the maximum memory usage of the patched and unpatched shells. Does this change in zhalloc() make any difference? This goes farther in the direction of abandoning small bits of earlier arenas until the popheap() comes around. diff --git a/Src/mem.c b/Src/mem.c index b9569ea..63a5afe 100644 --- a/Src/mem.c +++ b/Src/mem.c @@ -543,9 +543,14 @@ zhalloc(size_t size) /* find a heap with enough free space */ - for (h = ((fheap && ARENA_SIZEOF(fheap) >= (size + fheap->used)) - ? fheap : heaps); - h; h = h->next) { + /* + * This previously assigned: + * h = ((fheap && ARENA_SIZEOF(fheap) >= (size + fheap->used)) + * ? fheap : heaps); + * but we think that nothing upstream of fheap has more free space, + * so why start over at heaps just because fheap has too little? + */ + for (h = (fheap ? fheap : heaps); h; h = h->next) { if (ARENA_SIZEOF(h) >= (n = size + h->used)) { void *ret;