From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Kraft Newsgroups: gmane.lisp.guile.devel Subject: Re: Elisp performance Date: Fri, 31 Jul 2009 08:09:08 +0200 Message-ID: <4A728A84.1010106@domob.eu> References: <4A7045AC.10407@domob.eu> <87ocr1yle9.fsf@arudy.ossau.uklinux.net> NNTP-Posting-Host: lo.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 1249020544 9048 80.91.229.12 (31 Jul 2009 06:09:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 31 Jul 2009 06:09:04 +0000 (UTC) Cc: Andy Wingo , guile-devel , Neil Jerram To: Ken Raeburn Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Fri Jul 31 08:08:56 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MWlIV-0003dT-Tn for guile-devel@m.gmane.org; Fri, 31 Jul 2009 08:08:56 +0200 Original-Received: from localhost ([127.0.0.1]:53377 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWlIU-0000b9-KS for guile-devel@m.gmane.org; Fri, 31 Jul 2009 02:08:54 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MWlIK-0000b2-Bt for guile-devel@gnu.org; Fri, 31 Jul 2009 02:08:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MWlIF-0000ap-Oh for guile-devel@gnu.org; Fri, 31 Jul 2009 02:08:43 -0400 Original-Received: from [199.232.76.173] (port=51810 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MWlIF-0000am-L9 for guile-devel@gnu.org; Fri, 31 Jul 2009 02:08:39 -0400 Original-Received: from taro.utanet.at ([213.90.36.45]:43453) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MWlIF-0003xC-0f for guile-devel@gnu.org; Fri, 31 Jul 2009 02:08:39 -0400 Original-Received: from paris.xoc.tele2net.at ([213.90.36.7]) by taro.utanet.at with esmtp (Exim 4.69) (envelope-from ) id 1MWlIC-0003ia-LP; Fri, 31 Jul 2009 08:08:36 +0200 Original-Received: from d86-32-16-119.cust.tele2.at ([86.32.16.119] helo=[192.168.1.18]) by paris.xoc.tele2net.at with esmtpa (Exim 4.69) (envelope-from ) id 1MWlIC-0003Vj-Gq; Fri, 31 Jul 2009 08:08:36 +0200 User-Agent: Thunderbird 2.0.0.0 (X11/20070425) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9002 Archived-At: Ken Raeburn wrote: > And maybe that's enough. There's other stuff in Emacs besides variable > bindings that would require dynamic-wind support, like flet, > save-excursion (preserves current buffer and position), > with-output-to-string and with-output-to-temp-buffer (preserve > 'standard-output'), as well as any number of explicit calls to > unwind-protect from Elisp code to alter and restore other global state > of the program (e.g., with set-default-file-modes or > set-standard-case-table). The current incarnation of these things > assumes a single-threaded execution model. So, since we can't make > Emacs multithreaded by simply dropping Guile Elisp into it, if Emacs is > all we're concerned about, maybe assuming single-threaded execution only > is okay for now. > > On the other hand, if we want users to be able to write code snippets in > Elisp and have them callable from a concurrently-multithreaded Scheme > program (no Emacs processes in sight), I think we'll want the > multithreaded support for the basic Elisp language sooner rather than > later, even if multithreaded Emacs needs much more work. As already stated upthread, I'm not sure about this myself... It would be cool to stay as flexible as possible with regards to future multi-threading, but on the other hand I also like the idea of getting rid of the fluids. My timings there seem to suggest that fluids at least have "some" performance hit. Of course, anyone interested in performance can also use lexical-let instead of let and also get rid of all this performance problems as well ;) But the same argument may hold for the threading argument, too, so if you want to write elisp code that is called from multi-threaded Scheme, just avoid dynamic binding and you'll get no problems... > I also don't know how complicated a switch to stop using fluids would > be. If it's not too painful, the performance impact would be > interesting to see -- does it get us closer to the performance of Emacs > itself? Well, it will not be trivial but also quite doable, I think. Regarding the performance, I'm quite sure it will help, but not so much about the actual quantitative impact -- but if we're lucky, it might be like that between dynamic and lexical let of my timings in the original post. This seems quite plausible to me. Daniel -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri