From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29947 invoked by alias); 13 Oct 2015 15:52:56 -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: 36853 Received: (qmail 22462 invoked from network); 13 Oct 2015 15:52:53 -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=Pmer01idkp3/jeOMn5w1KhpxeaRXphJcdBr1uY/PLbc=; b=DZhTpooMjgmRkCdyTT5UYwpRU/zSb9aFA+p0f3DV0HAMKGoiXPrNARQiEpNX5Y3UVF 79OCdzioU+ezPqaw9D87baVxTIRJJMdy50Dp1n325e3yoNMZjFmdD9ucdiQmtulmjQ6B oTs6sZEul/RulMgp2aSvWk81On4t26ZU3yyDqY3q1pmA87/0xwk3zO334a14Zw0eB1/v G/7j8NZRMNqWADY3t3sFRYXO+mvbj1HYTysJ0NABirfHhXqsNKMZfMvAhcUy2WMdTlX/ uMOW9lkLqxS4OzV+7FXu/V/TzGOVsRyJCPu4TpC0+BJ00vuoo0tM3I029z2v3epiDOk3 xC4A== X-Gm-Message-State: ALoCoQl0DZlRE9SoZON0I2jKNEx6L5Tn9Xw0+WEVh65GKC18Q6fm1EAAtnh6TNTPvHPybkSYMEsF X-Received: by 10.202.190.87 with SMTP id o84mr19136208oif.111.1444751569873; Tue, 13 Oct 2015 08:52:49 -0700 (PDT) From: Bart Schaefer Message-Id: <151013085246.ZM30504@torch.brasslantern.com> Date: Tue, 13 Oct 2015 08:52:46 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: Slowdown around 5.0.5-dev-0" (Oct 13, 10:21am) References: <151010105849.ZM10144@torch.brasslantern.com> <151010170623.ZM16166@torch.brasslantern.com> <151010232045.ZM12931@torch.brasslantern.com> <151011091757.ZM27755@torch.brasslantern.com> <151011103121.ZM8814@torch.brasslantern.com> <151011142204.ZM9103@torch.brasslantern.com> <151012070105.ZM15099@torch.brasslantern.com> <151012173304.ZM15477@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 13, 10:21am, Sebastian Gniazdowski wrote: } } I meant that maybe the numbers yield some optimization strategy. } I could try to implement it. But maybe there is nothing left to be } done? I think we're all out of low-level strategies without completely redoing the algorithm. As I noted, it's optimized mostly for space rather than speed. Based on your later two emails, we've increased memory footprint by about 25% in order to get a significant increase in speed, so that is probably an OK trade-off on most modern hardware. At this point I think any gains would be found higher up -- calls to push/pop the heap that aren't necessary, or places [similar to the use in completion code] where we could replace push/pop with a NEWHEAPS() block to avoid scanning existing heaps for free space. For example, the following shows what I mean. This may be a poor choice if most functions are small, so I won't suggest committing, but this is the kind of well-isolated push/pop that might benefit. diff --git a/Src/exec.c b/Src/exec.c index bcc8065..b9c40df 100644 --- a/Src/exec.c +++ b/Src/exec.c @@ -5067,10 +5067,11 @@ doshfunc(Shfunc shfunc, LinkList doshargs, int noreturnval) #ifdef MAX_FUNCTION_DEPTH static int funcdepth; #endif + Heap funcheap; queue_signals(); /* Lots of memory and global state changes coming */ - pushheap(); + NEWHEAPS(funcheap) { oargv0 = NULL; obreaks = breaks; @@ -5290,7 +5291,8 @@ doshfunc(Shfunc shfunc, LinkList doshargs, int noreturnval) numpipestats = oldnumpipestats; memcpy(pipestats, oldpipestats, sizeof(int)*numpipestats); } - popheap(); + + } OLDHEAPS; unqueue_signals();