From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: taylanbayirli@gmail.com (Taylan Ulrich =?utf-8?Q?Bay=C4=B1rl=C4=B1?= =?utf-8?Q?=2FKammer?=) Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Sat, 17 Oct 2015 20:34:15 +0200 Message-ID: <87pp0duyxk.fsf@T420.taylan> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <87oag4jk74.fsf@wanadoo.es> <87k2qrki45.fsf@wanadoo.es> <8737xf9je9.fsf@fencepost.gnu.org> <87pp0fm0j3.fsf@gnu.org> <87r3kusx8z.fsf@fencepost.gnu.org> <83lhb26eb9.fsf@gnu.org> <876126key3.fsf@gnu.org> <83fv1a6bfu.fsf@gnu.org> <87d1weo7u9.fsf@gnu.org> <83zizi3qr0.fsf@gnu.org> <87lhb1n81y.fsf@gnu.org> <87a8rhqzdd.fsf@fencepost.gnu.org> <871tctxy1a.fsf@T420.taylan> <87twpppgtq.fsf@fencepost.gnu.org> <87bnbxwgd3.fsf@T420.taylan> <87d1wdpf1c.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1445106865 31298 80.91.229.3 (17 Oct 2015 18:34:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 17 Oct 2015 18:34:25 +0000 (UTC) Cc: Ludovic =?utf-8?Q?Court=C3=A8s?= , Eli Zaretskii , emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 17 20:34:24 2015 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 1ZnWJD-00085A-CM for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 20:34:23 +0200 Original-Received: from localhost ([::1]:59448 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnWJC-00016c-Ka for ged-emacs-devel@m.gmane.org; Sat, 17 Oct 2015 14:34:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35788) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnWJ8-00016X-UW for emacs-devel@gnu.org; Sat, 17 Oct 2015 14:34:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZnWJ7-0003VD-VL for emacs-devel@gnu.org; Sat, 17 Oct 2015 14:34:18 -0400 Original-Received: from mail-wi0-x236.google.com ([2a00:1450:400c:c05::236]:38787) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZnWJ7-0003Ut-P5; Sat, 17 Oct 2015 14:34:17 -0400 Original-Received: by wicll6 with SMTP id ll6so50373720wic.1; Sat, 17 Oct 2015 11:34:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type:content-transfer-encoding; bh=F7rWTBGLFs6P1rq5YwqDQCMzBrhqfeL663Q34wqUa0E=; b=pSRjlPQ9cwII3hniqe8et+//wilPWM9GzB29nzV7tDqX3hoLKgXnRcCIND1+xYRs35 Im2t8+vhe5liCl3RS+NM79RLgwLb4n0W1yWIjMnB4ih7RVX9a6JyYMAyr3v/7mTuO5ff AZuunw2Gx/V7SmKQoNVqA1uowNzZD/njb4Irshw+iX+54KAGS/99M1BQbMChpZqbRtRF RxzlkpAQKHLQiBU0tImacbRChhbxlAneXZ0iVwNhWtWfV3DlfTOSPGJBpsz+FLdpvlVh BiYRomOmtQnDwsx0uwrqP+orYKJ5F6aWuLJqJJMg9G873QLs5b8kc+8JFfHnx6u0S5OB 6dow== X-Received: by 10.180.223.102 with SMTP id qt6mr11758548wic.11.1445106857150; Sat, 17 Oct 2015 11:34:17 -0700 (PDT) Original-Received: from T420.taylan ([2a02:908:c32:4740:221:ccff:fe66:68f0]) by smtp.gmail.com with ESMTPSA id v9sm12766854wjv.45.2015.10.17.11.34.15 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Oct 2015 11:34:16 -0700 (PDT) In-Reply-To: <87d1wdpf1c.fsf@fencepost.gnu.org> (David Kastrup's message of "Sat, 17 Oct 2015 19:42:55 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::236 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:191871 Archived-At: David Kastrup writes: > taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") writes: > >> David Kastrup writes: >> >>> taylanbayirli@gmail.com (Taylan Ulrich "Bay=C4=B1rl=C4=B1/Kammer") writ= es: >>> >>>> I haven't followed the whole discussion but I'd like to remind that >>>> GuileEmacs already runs currently, and from what I know none of the >>>> problems it faces are related to string handling. It just lets Elisp >>>> strings be a separate data type. >>>> >>>> I guess the discussion was about rewriting bigger parts of Emacs in >>>> Guile-Scheme, which might be one possible way to go forward but not >>>> necessary. >>>> >>>> Most of the benefits in e.g. http://www.emacswiki.org/emacs/GuileEmacs >>>> apply without having to solve the string problem. Specifically, from >>>> the overview section, the first two points and half of the third should >>>> apply I think. >>> >>> The first two points concern efficiency. Emacs is _all_ about working >>> with strings, and the last report of GuileEmacs stated something like >>> GuileEmacs being about an order of magnitude slower specifically because >>> of having to special-case Emacs strings and buffers. >>> >>> Emacs is first and foremost an editor. Substantial increases of >>> efficiency in most general programming areas at the cost of abysmal >>> performance in text processing are not going to make the race. >> >> I think you're misremembering. > > So performance is comparable? Regarding Elisp string munging, probably, since the same C code as before applies. >> It might be that you have strings in mind because not being able to >> serialize Elisp strings means having to compile everything at each >> startup, making startup slow. And maybe you have buffers in mind >> because buffer-local variables and other weird binding semantics of >> Elisp need special handling. >> >> Neither is related to the run-time performance of string handling, of >> course. >> >> Hmm, what would be a good benchmark of Elisp string handling that >> won't be affected by the performance of dynamic binding of variables >> or other such things? I'd like to just test it instead of >> hypothesize. > > Most relevant candidates are likely file load/save, string display and > stuff like regexp searches through buffers. Opening a 30 MB IRC log file takes the same amount of felt time as on upstream Emacs. Saving it too. (while (re-search-forward "taylan" nil t) (ignore)) in the same file is pretty much instant on both. I think there's simply no speed difference in string munging on GuileEmacs so far. It really just uses the existing C "subrs". Taylan