From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? (WAS: bug#24358) Date: Sat, 29 Oct 2016 09:37:01 +0300 Message-ID: <83twbvr78y.fsf@gnu.org> References: <87twe6sx2g.fsf@users.sourceforge.net> <87eg51ng4r.fsf_-_@users.sourceforge.net> <87k2djwumn.fsf@users.sourceforge.net> <83h98nidvd.fsf@gnu.org> <87eg3rvtsf.fsf@users.sourceforge.net> <83k2dihpm9.fsf@gnu.org> <8760p2wzgj.fsf@users.sourceforge.net> <838ttyhhzu.fsf@gnu.org> <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <83d1iq5ib1.fsf@gnu.org> <83r3753c8j.fsf@gnu.org> <83r374wh32.fsf@gnu.org> <83wpgtrmt2.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477723070 2423 195.159.176.226 (29 Oct 2016 06:37:50 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2016 06:37:50 +0000 (UTC) Cc: eggert@cs.ucla.edu, emacs-devel@gnu.org, npostavs@users.sourceforge.net To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 29 08:37:46 2016 Return-path: Envelope-to: ged-emacs-devel@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 1c0NGq-0007LM-E8 for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 08:37:36 +0200 Original-Received: from localhost ([::1]:53454 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0NGs-0002Er-UH for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 02:37:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45299) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0NGJ-0002EM-Fo for emacs-devel@gnu.org; Sat, 29 Oct 2016 02:37:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0NGG-0001Sl-3S for emacs-devel@gnu.org; Sat, 29 Oct 2016 02:37:03 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47577) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0NGF-0001Sf-W1; Sat, 29 Oct 2016 02:37:00 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4660 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1c0NG8-0007GZ-O5; Sat, 29 Oct 2016 02:36:53 -0400 In-reply-to: (message from Richard Stallman on Fri, 28 Oct 2016 15:12:27 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:208956 Archived-At: > From: Richard Stallman > CC: eggert@cs.ucla.edu, npostavs@users.sourceforge.net, > emacs-devel@gnu.org > Date: Fri, 28 Oct 2016 15:12:27 -0400 > > > The Lisp approach has a huge advantage: it is much simpler, so > > everyone here will understand it, and it is much easier to maintain > > and develop. > > The special format I propose is simple enough. For you and me (and a few others), maybe. For most of the current Emacs contributors it's nowhere near "simple enough", because it requires one to be familiar with intimate details of Emacs object design and implementation. IOW, for the purposes of this discussion, I consider anything that is not mostly Lisp "not simple". > > So if the performance hit is bearable (meaning will be accepted by the > > crowd), it should IMO be preferred for reasons of project management > > and its future, > > Slowness here affects every user and is quite noticeable. > Don't we already know that Lisp is too slow for this? No, we don't know that, because we never tried to implement any method of reading compiled Lisp that is optimized for speed and targets a bare Emacs. E.g., it turned out that most of the time it takes 'loadup' to do its job is due to the linear search of pure strings in find_string_data_in_pure, called by make_pure_string. If we call 'loadup' upon every startup, the need for pure storage goes away, and the 'loadup' time can be sped up tenfold. And that is even before making all of the preloaded files a single file, which speeds up things at least twofold more, according to my measurements. So here you have a 20-fold speedup just by two very simple measures. > > care about the future of Emacs in the face of the fact that fewer and > > fewer people know, or even want to know, about segments and offsets in > > a binary executable file. > > That is an argument for replacing unexec with something that saves the > data to reloed, but it is not an argument for using Lisp as the format. It is an argument for both, because I don't think we can count on too many people here being able to tinker with Lisp object internals in the future. The less such features we have that will need maintenance, the better for Emacs viability in the long run. > > time emacs -batch --eval t > > I just tried it with my current build (from June). It took .26 seconds, > which is fast enough. > > If replacing unexec with loading Lisp takes .05 seconds more, I won't > complain. But I think it will take several seconds, if not minutes. How much does it take on your system to do this: time src/temacs -batch -l loadup And if you modify Emacs with the patch posted here: http://lists.gnu.org/archive/html/emacs-devel/2016-01/msg01049.html how long does it take temacs to loadup then?