From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#15294: 24.3.50; js2-mode parser is several times slower in lexical-binding mode Date: Sun, 15 Sep 2013 03:11:41 +0300 Message-ID: <5234FB3D.40209@yandex.ru> References: <871u51ll93.fsf@yandex.ru> <5233E40D.4000102@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1379203939 12294 80.91.229.3 (15 Sep 2013 00:12:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Sep 2013 00:12:19 +0000 (UTC) Cc: 15294@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Sep 15 02:12:21 2013 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VKzwr-0000SC-6E for geb-bug-gnu-emacs@m.gmane.org; Sun, 15 Sep 2013 02:12:21 +0200 Original-Received: from localhost ([::1]:55008 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKzwq-0006xF-OK for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2013 20:12:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49259) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKzwf-0006x5-Th for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2013 20:12:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VKzwY-0002oq-Jv for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2013 20:12:09 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:57336) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VKzwY-0002oa-G4 for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2013 20:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1VKzwY-0004Ro-5W for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2013 20:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Sep 2013 00:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 15294 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 15294-submit@debbugs.gnu.org id=B15294.137920391517084 (code B ref 15294); Sun, 15 Sep 2013 00:12:02 +0000 Original-Received: (at 15294) by debbugs.gnu.org; 15 Sep 2013 00:11:55 +0000 Original-Received: from localhost ([127.0.0.1]:37396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VKzwR-0004RT-0X for submit@debbugs.gnu.org; Sat, 14 Sep 2013 20:11:55 -0400 Original-Received: from mail-ea0-f176.google.com ([209.85.215.176]:64960) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1VKzwN-0004R8-UW for 15294@debbugs.gnu.org; Sat, 14 Sep 2013 20:11:52 -0400 Original-Received: by mail-ea0-f176.google.com with SMTP id q16so1294961ead.35 for <15294@debbugs.gnu.org>; Sat, 14 Sep 2013 17:11:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=1+gYmxHgCYVVH/e/X1o+jIXWNBye5/J99NqqfgruBjQ=; b=BCQtr4rl/6SEmOJzz8hMSm4ZwULwhyH4nMpoc8OZg04FlCCbZnShE/Wqvqat1bnVL/ Erc6uuRWV4SrIUM5qhwEABk4uSgaLsDomWtuRvOjf9Qj9F3zUIQ0ImKqWq07AxIASwJh KXCKTmW++CiqN7+dPK8hoh28W/wcZBrvf4IQke/vL8fcm8r2FD37B0FQJWkHZpsxzNZh +b3r1SOchI7vZoydVi7JzufJo0XTTLKp/Xd16xzghLN+U0ifqzkALKmV2NaZ4odkLwbL vlsrn24n9HvOKE9ZF8elF9ykKMgDoRNKuOP3gl3s1Dp1z2LNGuFQWRz001YHJMofK93v JzeQ== X-Received: by 10.14.241.74 with SMTP id f50mr30520700eer.29.1379203905962; Sat, 14 Sep 2013 17:11:45 -0700 (PDT) Original-Received: from [192.168.10.2] (62-118-214.netrun.cytanet.com.cy. [62.228.118.214]) by mx.google.com with ESMTPSA id j7sm28180708eeo.15.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 14 Sep 2013 17:11:45 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:78409 Archived-At: On 14.09.2013 17:27, Stefan Monnier wrote: >>> It seems the slowdown is indeed linked to the way `catch' is handled >>> (indeed, this non-idiomatic ELisp code ends up byte-compiled in a really >>> poor way). >> What's non-idiomatic about this use of `catch'? > > The non-idiomatic part is the "one big let on top, with lots of setq > inside". It's clearly C code in Elisp syntax. Or rather Java code, considering its origins. In general, we have to stay close enough to the SpiderMonkey codebase to be able to port new syntax features easily. You've explained how this is bad when combined with closures, but other than gotchas with `catch' (and `condition-case', I'm assuming), we don't have any higher-order functions in the parser. No lambda forms anywhere, at least. Can the fact that `dotimes', `dolist' and `loop' are advised with `cl--wrap-in-nil-block', which expands into `catch' form, make much of a difference? >> It does not make much of a difference in the interpreted mode. > > The interpreted performance is affected by completely different factors. > My guess for the interpreted case is that there are simply "too many" > local variables: the environment is represented by a simple alist, so > variable lookup time is proportional to the number of local variables. > That fine when there are 5 local variables, but is inefficient when you > have 100 (better would be a balanced tree or maybe a hash table). `js2-get-token' has 13 local variables (*). Which is, while not a little, far from 100. Most of the other functions have fewer than that. Are you counting the global variables, too? The dynamic-binding interpreter has to work with them, too. How is it that much faster? (*) According to Steve's notes, symbol lookup in alists is faster than in Emacs hashtables until 50+ elements. Or was, around the year 2009. > This said, I'm not terribly concerned about it: if you need it to go > fast, you should byte-compile the code. I guess so. The sloppy users who disregarded the instructions to byte-compile the code were actually creating a bad reputation for js2-mode 1-2 years ago, but since package.el is much more popular now, it should be less of a problem. >> But 2.6 vs 2.1, it still a noticeable regression. Do you suppose the usage >> of `setq' is the main contributor? > > The problem goes as follows: ... Thank you for the detailed explanation. There are a few `catch' forms left there, for tags `continue' and `break', used for control flow. So, most of the 0.5s difference left is likely due to them, right? I wonder how hard it'll be to rewrite that without `catch'. >> (*) Would you take a look at it, too? It has quite a few changes in >> js2-get-token' and related functions. > >> They also make performing the same change as in your patch more >> difficult, since I'm actually using the value returned by `catch' >> before returning from the function. > > That's not a problem. The rule to follow is simply: sink the `let' > bindings closer to their use. You don't need to `let' bind all those > vars together in one big `let': you can split this let into various > `let's which you can then move deeper into the code. In some cases > you'll find that some of those vars don't even need to be `setq'd any > more. Thanks, will do.