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: Skipping unexec via a big .elc file Date: Mon, 24 Oct 2016 13:00:35 +0300 Message-ID: <831sz65anw.fsf@gnu.org> References: <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> <8360ojpndr.fsf@gnu.org> <83shrnm0k1.fsf@gnu.org> <83insi5jy9.fsf@gnu.org> <83bmya5i7q.fsf@gnu.org> <834m425eb5.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477303273 5277 195.159.176.226 (24 Oct 2016 10:01:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 10:01:13 +0000 (UTC) Cc: schwab@suse.de, larsi@gnus.org, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 12:01:05 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 1byc3q-0007bb-Cc for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 12:00:54 +0200 Original-Received: from localhost ([::1]:45616 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byc3s-0003TD-J5 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 06:00:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51921) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byc3g-0003Qn-RS for emacs-devel@gnu.org; Mon, 24 Oct 2016 06:00:48 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byc3b-0000US-6M for emacs-devel@gnu.org; Mon, 24 Oct 2016 06:00:44 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byc3a-0000UN-TG; Mon, 24 Oct 2016 06:00:39 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1721 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byc3Z-0001w0-Rx; Mon, 24 Oct 2016 06:00:38 -0400 In-reply-to: (message from Daniel Colascione on Mon, 24 Oct 2016 02:47:03 -0700) 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:208669 Archived-At: > Cc: larsi@gnus.org, emacs-devel@gnu.org > From: Daniel Colascione > Date: Mon, 24 Oct 2016 02:47:03 -0700 > > >> $ time emacs --batch --eval t > >> 0.027user 0.011system 0m0.048selapsed 79.66%CPU > > > > Then I guess you will have to continue using unexec, and when that > > alternative disappears, switch to some other editor. > > > > I have lots of scripts that run using emacs -Q --batch; many are invoked > frequently in other scripts. Making each take 250ms instead of 27ms to > run will greatly increase the overall runtime of the high-level > operations. Maybe --batch won't need to load all of the elc code, maybe we could have a smaller batch.elc for that. Or maybe what Ken just wrote will bring the load time below 100 ms, who knows. IOW, I think we are arguing prematurely about something whose performance we don't really understand, haven't measured yet, and haven't even written yet. Doesn't sound like a good idea. > I don't see a need to regress performance here, since a > custom malloc will perform at least as well as the last glibc malloc > that supported unexec (since it could in principle be a literal copy of > that code), and we found the performance of that malloc acceptable. I > care _much_ more about runtime performance than I do about allocation > throughput once started. The desire to drop unexec is not just because of malloc, it's because advances in compilers, linkers, and system security make maintenance of unexec harder and harder. For example, unexec is incompatible with address sanitation and other similar security techniques. It also regularly breaks when some new section is invented by the linker. Etc. etc. Therefore, we already decided to move towards eliminating unexec, and the only issue we should discuss is how to do that. You are in fact suggesting to overturn that decision, which I don't think people will agree with.