From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Performance of lexical closures in interpreted code? (was Re: Execution speed) Date: Mon, 20 Mar 2017 08:50:32 -0400 Message-ID: References: <87lgs13wz2.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1490014259 27136 195.159.176.226 (20 Mar 2017 12:50:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 20 Mar 2017 12:50:59 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 20 13:50:56 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cpwly-0006X5-ER for ged-emacs-devel@m.gmane.org; Mon, 20 Mar 2017 13:50:54 +0100 Original-Received: from localhost ([::1]:32795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cpwm4-0006zy-Eb for ged-emacs-devel@m.gmane.org; Mon, 20 Mar 2017 08:51:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cpwly-0006zh-LS for emacs-devel@gnu.org; Mon, 20 Mar 2017 08:50:55 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cpwlt-0001qw-RV for emacs-devel@gnu.org; Mon, 20 Mar 2017 08:50:54 -0400 Original-Received: from [195.159.176.226] (port=55161 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cpwlt-0001qT-Jt for emacs-devel@gnu.org; Mon, 20 Mar 2017 08:50:49 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cpwlg-0004rC-UN for emacs-devel@gnu.org; Mon, 20 Mar 2017 13:50:36 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 42 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:dnZ4atlCeyHSQW5NSV+XwmzMe8g= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:213176 Archived-At: > Tangentially, that performance hit on the interpreted recursive > code with lexical-binding enabled is pretty severe! From well under > 2 seconds (with dynamic binding) to well over 4 seconds (with lexical > binding) in all my results. > Is this a known/accepted trade-off for the better byte-compiled > performance? Yes and no: I consider the performance of interpreted code to be basically irrelevant, so I haven't paid any attention to it when introducing the lexical-binding functionality: when performance matters, the code should be compiled. > I'm assuming it's to do with overheads of lexical closures. As you can guess from the above, I don't really know. But I'd be surprised if it's the case. A more likely reason is the handling of the lexical environment (e.g. all the let-rebinding of the dynamically-scoped var which holds the lexical environment). > The output npostavs generates indicates that it's largely (if > not solely) on account of a vast quantity of garbage collection. > Perhaps that is all the lexical environments being cleaned up? Quite likely, yes. > (Although I would have thought that was a requirement for the > byte-compiled code as well, so I'm very much guessing.) The lexical environment is mostly "compiled away". In the bytecode, new lexical vars are just pushed on the stack, whereas in interpreted code a new lexical var means adding a new element to an alist (i.e. 2 `cons`). > Can that be improved, or is this most likely to remain this way? Of course it can be improved. It might take a fair bit of effort, tho (e.g. I think to be more efficient, you'll likely want to pass the lexical-env as an additional argument rather than by storing it in a global (dynamically-scoped) var, but this will require changes to all the special forms (grep for UNEVALLED)). Stefan