From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.help Subject: Re: Optimising Elisp code Date: Fri, 05 Oct 2018 16:42:31 +0200 Organization: Aioe.org NNTP Server Message-ID: <86r2h44fqg.fsf@zoho.com> References: <638fb7dc-6fc5-4645-8793-97a00038a3a8@googlegroups.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1538750600 24620 195.159.176.226 (5 Oct 2018 14:43:20 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 5 Oct 2018 14:43:20 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4 (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 Oct 05 16:43:16 2018 Return-path: Envelope-to: geh-help-gnu-emacs@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 1g8RK0-0006Ij-6V for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Oct 2018 16:43:16 +0200 Original-Received: from localhost ([::1]:35498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1g8RM6-0002o5-PJ for geh-help-gnu-emacs@m.gmane.org; Fri, 05 Oct 2018 10:45:26 -0400 X-Received: by 2002:a1c:13ce:: with SMTP id 197-v6mr1262489wmt.5.1538750552656; Fri, 05 Oct 2018 07:42:32 -0700 (PDT) Original-Path: usenet.stanford.edu!s185-v6no886752wmd.0!news-out.google.com!z77-v6ni2449wmz.0!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder1-1.proxad.net!ecngs!feeder2.ecngs.de!78.46.240.70.MISMATCH!weretis.net!feeder4.news.weretis.net!news.mixmin.net!aioe.org!.POSTED!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 56 Original-NNTP-Posting-Host: xQsFb8j6c/kdg9AvIrnVFA.user.gioia.aioe.org Original-X-Complaints-To: abuse@aioe.org Cancel-Lock: sha1:bYlZXhHSjhkL3Z8T3b0MVUXUUAI= X-Notice: Filtered by postfilter v. 0.8.3 Mail-Copies-To: never Original-Xref: usenet.stanford.edu gnu.emacs.help:223999 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:118125 Archived-At: Barry Margolin wrote: > You can also define an inline function using > defsubst. From the Elisp manual: > > An inline function works just like an > ordinary function except for one thing: when > you compile a call to the function, the > function's definition is open-coded into > the caller. This rings a bell from the C++ days when/where you could define a member function as "inline". That's all I remember, but maybe it was something similar to this? I think it amounted to, instead of making a call, that function was coded into the object itself, and for this reason it was suited for really short, simple functions. Yes, what does it mean that "the function's definition is open-coded into the caller"? If the caller is a function, does this mean instead of calling the other function, the other function's code is put into the first function so there isn't a second call but everything is executed in the first function? > Making a function inline makes explicit calls > run faster. Well, yeah, obviously since there is no second invocation with just the original function put onto the stack! What are "explicit calls"? Regular calls, right? But then what are implicit calls? Anonymous functions? Or is an inline function being executed an implicit call to that function? > But it also has disadvantages. For one thing, > it reduces flexibility; if you change the > definition of the function, calls already > inlined still use the old definition until > you recompile them. Another good point, but that's obvious as well. (Hey, for a person who doesn't understand this, I sure sound confident enough :)) -- underground experts united http://user.it.uu.se/~embe8573