Path: utzoo!attcan!uunet!odi!dlw From: dlw@odi.com (Dan Weinreb) Newsgroups: comp.lang.lisp Subject: Re: Linking and MACL (really efficiency of local functions) Message-ID: <1989Nov24.154940.9739@odi.com> Date: 24 Nov 89 15:49:40 GMT References: <21316@brunix.UUCP> <1989Nov20.150510.20700@hellgate.utah.edu> <31762@news.Think.COM> Reply-To: dlw@odi.com Organization: Object Design, Inc. Lines: 27 In-Reply-To: simon@packer.UUCP's message of 23 Nov 89 11:03:57 GMT In article simon@packer.UUCP (Simon Leinen) writes: This is what makes local functions expensive: They are called through a (synthetic) symbol's function cell. When you use the `production compiler' of Lucid Lisp, this overhead is avoided. As Sandra Loosemore argued, calls to local functions should be *cheaper* than calls to global functions. The Lucid implementation often integrates local functions into their callers, thus eliminating function call overhead *completely*. But remember, the earlier posting's complaint was that it was too hard to trace internal (local) functions. You can't have it both ways: if they are integrated, they certainly can't be traced. Actually, distinguishing between external and internal functions here is a red herring. What you really want is two modes: one in which debugging all works well, at the cost of performance, and another optimized for speed but in which debugging is more difficult. This should exist for all kinds of functions. In the Lisp machines, the goal was to design hardware so that you could have speed and debuggability at the same time; many people feel that they come close enough to this ideal that it's not worth having separate compiler modes (debug versus optimize), although the point is debatable.