From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: lexical-binding questions Date: Tue, 15 May 2012 09:55:05 -0400 Message-ID: References: <871umzrvfw.fsf@gmail.com> <87y5p64o3v.fsf@gmail.com> <33844651.post@talk.nabble.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT X-Trace: dough.gmane.org 1337090302 19166 80.91.229.3 (15 May 2012 13:58:22 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 15 May 2012 13:58:22 +0000 (UTC) Cc: Emacs-devel@gnu.org To: egnarts-ms Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue May 15 15:58:21 2012 Return-path: Envelope-to: ged-emacs-devel@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 1SUIGX-0001lB-B5 for ged-emacs-devel@m.gmane.org; Tue, 15 May 2012 15:58:17 +0200 Original-Received: from localhost ([::1]:38829 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUIGW-0007mr-Rp for ged-emacs-devel@m.gmane.org; Tue, 15 May 2012 09:58:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:39366) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUIGR-0007mT-Gs for Emacs-devel@gnu.org; Tue, 15 May 2012 09:58:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SUIGK-0004xt-Qs for Emacs-devel@gnu.org; Tue, 15 May 2012 09:58:11 -0400 Original-Received: from relais.videotron.ca ([24.201.245.36]:10833) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SUIGK-0004wl-Np for Emacs-devel@gnu.org; Tue, 15 May 2012 09:58:04 -0400 Original-Received: from fmsmemgm.homelinux.net ([24.201.208.110]) by VL-VM-MR001.ip.videotron.ca (Oracle Communications Messaging Exchange Server 7u4-22.01 64bit (built Apr 21 2011)) with ESMTP id <0M4200ISVHGQWH10@VL-VM-MR001.ip.videotron.ca> for Emacs-devel@gnu.org; Tue, 15 May 2012 09:58:02 -0400 (EDT) Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 277FAAE27F; Tue, 15 May 2012 09:55:05 -0400 (EDT) In-reply-to: <33844651.post@talk.nabble.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 24.201.245.36 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:150494 Archived-At: > exec_byte_code currently allocates stack frames on a per-call basis, > according to what a byte-code object says about its max stack depth. It doesn't have to stay that way. > 1) doing direct call from exec_byte_code to exec_byte_code would most > evidently imply the same procedure: creating a new stack frame and copying > all the arguments (as Lisp_Objects) to it; You would call exec_byte_code but either call some new function or make no function call at all (thought that would probably require manually handling a separate "return address stack"). > 2) besides the above, going through Ffuncall does some additional things, > like checking lisp_eval_depth and performing GC if necessary, plus updating > the backtrace_list global variable. By all evidence, all these things must > also be performed when a byte-compiled function calls directly another > byte-compiled function, as you suggest, Yes, we'd have to duplicate some code and we can't eliminate all the overhead. Like all optimizations, it's difficult to know beforehand whether it will be worthwhile, but I think there are some significant savings to be had. In the same area, providing some way to do tail-call-optimization would be very welcome (tho only for lexical-binding code). Stefan