From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Mon, 24 Oct 2016 03:03:37 -0700 Message-ID: <2aea885d-c0dc-595f-3135-a564e92a905d@dancol.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> <831sz65anw.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1477303465 24633 195.159.176.226 (24 Oct 2016 10:04:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 10:04:25 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 Cc: schwab@suse.de, larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 12:04:16 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 1byc6q-0003am-C1 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 12:04:00 +0200 Original-Received: from localhost ([::1]:45624 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byc6s-00059Z-O5 for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 06:04:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52717) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byc6e-00055G-Fz for emacs-devel@gnu.org; Mon, 24 Oct 2016 06:03:52 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byc6a-0001JG-OK for emacs-devel@gnu.org; Mon, 24 Oct 2016 06:03:48 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:33738) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1byc6a-0001Ic-Dq; Mon, 24 Oct 2016 06:03:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=wWT1H/pFjUsV5aCz9PLwPeMHd55pIRNJQ9UXPqxO+Eg=; b=JS0BrQudQTNKWBdsZ/zptzFyiIkqttbD3mRFnVUhDbbTft5UsoLFoZyFR2l72X4HQpHfppDOM5Le5kvm8VXSlfr51y4QlSudb8l92Ct2GBl+uDz3Z136Ckf60Kf04cr08S66SjHOOTc8pWO0IgqyWBXP3TC+U8SbJUyqrPDT3dcVDTEc9jodhFIsJKZCrVJ0O2NI1uJKIxYDiKpR1mwX4cJwq02CNk8nD33m/usP3jXde2aIPtNu612fOuqxszbJ22pun+duLm+atYcVhGivix5iToz8Hr7lZTp6tYOgyF9i1NqVBOBo9AhsErVzD6k9hyEU6IFX/ArFtvkEV3mhBA==; Original-Received: from c-73-97-199-232.hsd1.wa.comcast.net ([73.97.199.232] helo=[192.168.1.173]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1byc6X-0002BS-U1; Mon, 24 Oct 2016 03:03:41 -0700 In-Reply-To: <831sz65anw.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:208670 Archived-At: On 10/24/2016 03:00 AM, Eli Zaretskii wrote: >> 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. Sure. I'd like to have a PIE Emacs myself. We're talking about methods. I don't think the XEmacs-style "portable dumper" approach, with relocations, has been given adequate consideration.