From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16596 invoked by alias); 10 Oct 2015 17:58: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: 36823 Received: (qmail 19384 invoked from network); 10 Oct 2015 17:58:55 -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=wJBLP4xoHh2WVe+wcVKCkH8AhQAQjfq/TXripm+kCPE=; b=hy8no1amNrUqKkwNmQGLadIkosNqF+ojdcTUogLjqBAq3RZkKZBYJ3GWOjAxVE8TNw 4EPTTZpm8Zys+T2VN+LjYFjY+goEOdKEBAfXS+qFbCoAwLLtbp7psl6DvBlxG+3547FB K9MAVZ0vsgtE07cArKCwtu22HYIbceofZiuXUb/2wDYwwTdjhoCpzCCf3zMX6iq6eQCu d416MHOL21rxt2RPn2pobCXCx91/bZ2tqXeecFh1BJIn4r4L4AwGTWBNjcL+0lR7smwq lbCx+VMIIdQU03/407mFr1XxSIKHKru6zA6FvnXvDvS3g72kV/3/PprvDdB2qgxhdrCG onRQ== X-Gm-Message-State: ALoCoQnUO9jrK8bNnT+Y5rhDb+2FPoxeh8vhrasSut/Lo7DkJ1Rd7/TczDwQMoozoUvPRIJDXIlb X-Received: by 10.202.176.9 with SMTP id z9mr11045925oie.105.1444499932775; Sat, 10 Oct 2015 10:58:52 -0700 (PDT) From: Bart Schaefer Message-Id: <151010105849.ZM10144@torch.brasslantern.com> Date: Sat, 10 Oct 2015 10:58:49 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Slowdown around 5.0.5-dev-0" (Oct 10, 12:54pm) References: 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 10, 12:54pm, Sebastian Gniazdowski wrote: } Subject: Slowdown around 5.0.5-dev-0 } } I was testing my scripts and saw that on 5.0.2 having 89k-elements } long is much faster than on 5.1.1-dev-0. I ran git bisect and found } the commit: } } 2014-01-18 23f98c3 32285: restart the fheap search in freeheap if the } current fheap arena is about to be discarded; fixes crash If you look back through the zsh-workers articles, you'll find that the performance was even worse prior to workers/29175; there was a huge gain in performance from that patch, but it introduced a crash bug, so we had to give back some of the performance in workers/32285 to prevent the crash from happening. Read the large comment in freeheap() for a description of what is going on there, note particularly the paragraph ending "performance goes to hell." I fear a signficant rewrite of the heap-allocation code would be needed to both avoid the crash and improve the performance. The current code was designed with the expectation that zhalloc() would be a much more common operation than freeheap(), but there are circumstances in which the latter happens a lot. It's possible that we could figure out a way to skip the scan that updates all the h->used values in freeheap(), and pay the price on the next zhalloc() instead. I think (but am not 100% sure) that the pathological case happens when the heap is already maximally filled, so a new arena is always added to the end of the chain and then dropped again on each alloc/free. On the other hand the shell really isn't intended to be manipulating arrays of containing tens of thousands of elements.