From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19047 invoked by alias); 14 Oct 2015 16:25:45 -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: 36858 Received: (qmail 20121 invoked from network); 14 Oct 2015 16:25:44 -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:in-reply-to:comments:to:subject:mime-version :content-type; bh=pbSz/3/R8ebZy/9NZFLEzxqyLluO1T1woJxk8E3zAJ4=; b=KanO8aSb4qZ+QLnB37tNZPvllhgBonYDCjMLjLCiFpgJbvqZ45JJu6c05ABxP0eGno i3J6w00CJosqnyfxYYMR6eEjaAevPV2tSlWSvs4nrCc/04LDN4W3m/K5LfIn67wwMpvX VJLtJWHM7k0VqzQcPKgvUUiCGrfvUy0fLkAHW/QmZv7D/a+V+MD5JzyIja3ua4+hWBcg +9fKqXZUxAGwBDIKrQTFrUlxKChfzP+rJRmrJl4v9lbDlkBcu47CW8u4/uZWrkwXVEr3 1ugoMdQM62/DVqy5EtChRghmGLRGj+KfRUk9Nchsye2+4F0/OGyGD4yTaGW13tlhh1tN bunA== X-Gm-Message-State: ALoCoQmj5A15yaOJGxXfJvaLZ5pPp/Aa1Yh9n8a8hY+3bGTyZ2yk5Bbyf47uUTk0VM8Y1x6g/8D4 X-Received: by 10.60.150.243 with SMTP id ul19mr2520109oeb.64.1444839939437; Wed, 14 Oct 2015 09:25:39 -0700 (PDT) From: Bart Schaefer Message-Id: <151014092536.ZM32511@torch.brasslantern.com> Date: Wed, 14 Oct 2015 09:25:36 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: Slowdown around 5.0.5-dev-0" (Oct 14, 8:50am) 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> <151013085246.ZM30504@torch.brasslantern.com> <20151014142722.282d0c5a@pwslap01u.europe.root.pri> In-Reply-To: <20151014142722.282d0c5a@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Slowdown around 5.0.5-dev-0" (Oct 14, 2:27pm) 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 14, 8:50am, Sebastian Gniazdowski wrote: } } With this patch the list is instant fast. NEWHEAPS() is O(1) where pushheap() is O(N) where N is the number of arenas already in the heap. So it's not suprising that it's faster in the specific case you're trying (lots of data in the heap for a relatively long time) -- the question is would it slow down in the more normal use case of a mostly-empty heap and a lot of function calls, because the one operation done by NEWHEAPS() is heavier than any one of the N operations in pushheap(). On the other hand for interactive use the difference in the small-memory case is probably never going to be noticed. } What's interesting is lower RES for the new patch. It's like with the } new patch RES can easier go down after peak. With pushheap() the code tries to maximally use available space in the already allocated heap arenas; with NEWHEAPS() that available space is ignored and we create all new arenas. It's possible that allows (or unintentionally forces) the system malloc() to clump new allocations together better so that they can be released back to the system sooner. A helpful side-effect if so, but I wouldn't count on it being true for all malloc libraries. On Oct 14, 2:27pm, Peter Stephenson wrote: } } I'd suggest a quick finger test with the completion system to see if } anything is obviously worse --- if anything is going to exercise large } function stacks with small-to-medium size functions, it's that. Actually the completion system is the place it's most likely to entirely break down -- completion already uses NEWHEAPS() to get its own heap, and then frequently employs SWITCHHEAPS() to be able to pass values back on the regular heap. If we're also swapping the regular heap around with NEWHEAPS() it's possible things might get very confused, or that an entire list of heaps might be leaked. However, I did just run the Test/Y* tests with valgrind and they all passed and reported no leaks. (I did get: ==32081== Warning: invalid file descriptor -1 in syscall close() ==32081== Warning: invalid file descriptor -1 in syscall close() from both Y01 and Y02 but curiously not Y03.)