From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Lexical binding doesn't seem to be faster? Date: Fri, 08 Mar 2019 00:39:09 -0500 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="259172"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Mar 08 06:39:38 2019 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h28EK-0015HD-PA for geh-help-gnu-emacs@m.gmane.org; Fri, 08 Mar 2019 06:39:36 +0100 Original-Received: from localhost ([127.0.0.1]:37454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h28EJ-0000Nq-NR for geh-help-gnu-emacs@m.gmane.org; Fri, 08 Mar 2019 00:39:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:52790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h28E6-0000NZ-5W for help-gnu-emacs@gnu.org; Fri, 08 Mar 2019 00:39:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h28E5-0003jf-7i for help-gnu-emacs@gnu.org; Fri, 08 Mar 2019 00:39:22 -0500 Original-Received: from [195.159.176.226] (port=50946 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h28E4-0003hh-Vr for help-gnu-emacs@gnu.org; Fri, 08 Mar 2019 00:39:21 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.89) (envelope-from ) id 1h28E3-00152a-1m for help-gnu-emacs@gnu.org; Fri, 08 Mar 2019 06:39:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ Cancel-Lock: sha1:E08XAqLZAjREK2SVYeuRDB0iIf4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:119582 Archived-At: > I've stumbled upon a discussion about converting Emacs code to a > faster lexical-binding and that help needed. While the semantics of lexical-binding does offer more opportunities for optimization, the current Elisp implementation does not make much effort to take advantage of it, so compiling with lexical-binding may generate code that goes marginally faster sometimes and marginally slower at other times simply because the code generated is a bit different, but in my experience there's rarely much difference either way. > The first bad sign happened to be sizes of cc-mode.elc: > > ;;; -*- lexical-binding: t -*- | 217581 > ;;; -*- lexical-binding: nil -*- | 212542 > > Lexical-binding bloats byte-code by 5KB. Odd. Indeed, in my experience lexical-binding tends to generate slightly larger .elc files. Not sure why, actually: I never bothered to investigate. Intuitively, I can't think of a good reason why that should be the case, so it may be a simple performance bug. [ BTW, a performance problem with lexical-binding was found during Emacs-24 which got fixed in Emacs-25, so I assume you're using a recent enough version which is not affected by this problem. ] > So, I took someone's function `with-timer` for benchmarking¹; Any reason why you didn't use `benchmark(-run(-compiled))`? > ;;; -*- lexical-binding: t -*- | 1.174s, 1.144s, 1.177s, 1.125s, 1.177s > ;;; -*- lexical-binding: nil -*- | 1.037s, 1.061s, 1.037s, 1.037s, 0.991s Hmmm... ~13% slowdown isn't terribly bad, but it's indeed rather disappointing. It'd be nice to try and compare the profiles in those two cases to try and see if the slowdown is just evenly spread (which would suck) or is neatly limited to a specific spot (which would be great). FWIW, the usual case where lexical-binding leads to bigger&slower code is when you pass a lambda-expression to another function and that lambda-expression has free variables (in the lexical-binding case, it requires building a closure which is rather costly currently, whereas in the dynamic-binding case it relies on the dynamic-scoping instead). So, for example, calls to `mapcar` where you pass a (lambda ...) that refers to variables from the context tend to be a bit more expensive (tho each iteration may be very slightly faster because the references to those variables can be slightly cheaper, so the overall impact may depend on the number of elements in the list). Stefan