From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: C and Emacs Lisp code parts Date: Fri, 1 Jul 2016 09:16:53 +0000 Message-ID: <20160701091653.GA2531@acm.fritz.box> References: <624c3d37-c829-7187-a699-7d7bbc211a20@online.de> <83ziq1u668.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1467364673 28915 80.91.229.3 (1 Jul 2016 09:17:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Jul 2016 09:17:53 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Andreas =?iso-8859-1?Q?R=F6hler?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 01 11:17:44 2016 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 1bIuZy-0004cy-77 for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 11:17:42 +0200 Original-Received: from localhost ([::1]:60595 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIuZx-0006zn-FB for ged-emacs-devel@m.gmane.org; Fri, 01 Jul 2016 05:17:41 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIuZB-0006zN-JL for emacs-devel@gnu.org; Fri, 01 Jul 2016 05:16:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bIuZ6-0002ry-G1 for emacs-devel@gnu.org; Fri, 01 Jul 2016 05:16:53 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:57950) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bIuZ6-0002qp-6h for emacs-devel@gnu.org; Fri, 01 Jul 2016 05:16:48 -0400 Original-Received: (qmail 60019 invoked by uid 3782); 1 Jul 2016 09:16:44 -0000 Original-Received: from acm.muc.de (p4FC46254.dip0.t-ipconnect.de [79.196.98.84]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Jul 2016 11:16:43 +0200 Original-Received: (qmail 2555 invoked by uid 1000); 1 Jul 2016 09:16:53 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:205023 Archived-At: Hello, Andreas. On Fri, Jul 01, 2016 at 10:39:26AM +0200, Andreas Röhler wrote: > On 01.07.2016 10:13, Eli Zaretskii wrote: > >> From: Andreas Röhler > >> Date: Fri, 1 Jul 2016 10:03:07 +0200 > >> last years parts of C code have been switched into the Lisp area. There > >> are pro and cons, the cons ..... I think you meant "pros" here. > >> ..... seems to be an easier maintenance, to protect against the > >> lack of skilled C-developers. Of course, that fails to protect against any lack of skilled Emacs Lisp developers. Which is more likely? > >> The backside is a general slowness, not felt in details of such a > >> change, but cumulated.Would liketo see this strategy changed.r Can you quantify this alleged general slowness? It could well be (and I suspect it is) that the rewriting of certain parts of Emacs in Lisp have had a negligible, unmeasureable impact on Emacs's speed. Can you be more specific, and identify some of these C -> Lisp changes which you suspect have slowed Emacs? To be honest, I'm not aware of any of these changes at all, with just a vague background awareness they may have taken place. > >> Rather focus at a fast and small core. Reduce the rate of changes > >> maybe. My preferred Emacs must not provide everything, but be quick > >> and reliable and easy to extend. I think it is all these things, though there is room for improvement (which is steadily happening). > >> Emacs Lisp seen as designed for the user-space. > > To compare performance, we need a performance test suite. Without > > measuring the impact of these changes, we cannot rationally discuss > > the alleged slowdown. > You need a number to believe function running from Emacs Lisp is slower > than an implementation in C? You need numbers to show that any such difference is important enough to suffer the disadvantages of C over Lisp for (slower, more difficult, maintenance, mainly). -- Alan Mackenzie (Nuremberg, Germany).