From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11603 invoked by alias); 12 Jun 2016 15:39:17 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 21656 Received: (qmail 23032 invoked from network); 12 Jun 2016 15:39:16 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:to:subject :mime-version; bh=cgEs3TIe1oIlPCvP7JqxaQG5lVYdjNPNl3GoTGkzi5U=; b=WQPCRjcZ1FgZq2CB+YG5IwDSDfqjcRNPfD5ssoQFnNJuYLg499qh/A0P9o6+DLQypm r3roygRPqqelMkXn5uIjyd4z4LQMUh6DzxD/EX6OBmCi32f5in59YS2j1ui5ae9OZ++O LJzedCFQwtdgfZhgjnjixfQ6hh1zqgVDSgp8EETvYgpVDst06vHpebSx61oSYrXFZ5RX KfxxQ9M5ESw7uZF/0++maPU2oa/5wNW1ftHqtaL8CxHt7OypQ38JcbgMTu4Q9VLc1ctA yVkSiuCKnX9kz5mlLI4wgMJhbFUdA9TS6Esnc3p59aM1ALG+1gxXT5sZNHyJNmfn5QhL 5p8w== 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; bh=cgEs3TIe1oIlPCvP7JqxaQG5lVYdjNPNl3GoTGkzi5U=; b=gE2M/Z//mktxisDLiXjRlKpgkm6MRkRw7umLOIJZI2cU3yS9jKB7toe5PdTbxn8iFA 1ON9XHFjDyt4n7ddwShDB0BdIO857U8FEjqtGtgyca7cABczZ6D67OXs3Ge9/BH5xwl/ OdQBtA4mJ3w/oqmIuLDAXXQhmttZUHpcvapikQFjoc+H+PXquAEuIjt/yqYa71qfnGoQ kKW29COehsBsWrrs+Ii6kmOc+DacKWYWIrzSs2pn8rMSZARObYR0XGwIR2myGGlchTCv sj08hjtGFzROr076wmGG2aXpmdlON1FJEYRtn0umo6YbQC3laBJqb1eiAyD1aPYuTS7B 0whw== X-Gm-Message-State: ALyK8tLSC3E5kgxeweL6wp8dVxGSXJfCOoBPan4ErB3JlS9aou1MvwMsFgclszEMu6807A== X-Received: by 10.66.161.73 with SMTP id xq9mr15750003pab.6.1465745952430; Sun, 12 Jun 2016 08:39:12 -0700 (PDT) From: Bart Schaefer Message-Id: <160612083928.ZM9485@torch.brasslantern.com> Date: Sun, 12 Jun 2016 08:39:28 -0700 In-Reply-To: Comments: In reply to Sebastian Gniazdowski "Re: One more heap optimization trick for zsh < 5.2" (Jun 11, 9:40am) References: <160508093530.ZM9686@torch.brasslantern.com> <160610203056.ZM10515@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: Zsh Users Subject: Re: One more heap optimization trick for zsh < 5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Jun 11, 9:40am, Sebastian Gniazdowski wrote: } } > It might have something to do with retaining the old copy } > of the function body until the call stack unwinds and it can safely } > be freed; a large value for $argv would therefore also hang around } > (two copies of it) for all of that time. } } That's apparently a hit. I attach two test files. I modified one of the tests to simply print $funcstack in each of the possible function calls on one pass (repeat 1). That yields: Normal autoload: aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt aload_fun aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt Special autoload: aload_fun_main (eval) aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt aload_fun (eval) aload_fun aload_fun_main (eval) aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt More special autoload: --reload-and-run aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt aload_fun_main --reload-and-run aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt --reload-and-run aload_fun aload_fun_main --reload-and-run aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt aload_fun --reload-and-run aload_fun aload_fun_main --reload-and-run aload_fun_main /home/schaefer/Mail/detach.dir/aload.zsh2.txt So the "more special" version makes twice as many function calls as the "special" one, and both of the latter have deeper call stacks than the "normal" one. From your timings, "more special" takes about twice as long as either, which sort of makes sense given double the number of calls. However, that doesn't explain why it remains slow in the n-list loop. I again changed aload_fun_main (fbody1) to use "repeat 2" and it does not show any extra call stack depth on the second pass, so it's not that it is e.g. somehow finding the "wrong" aload_fun body.