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 16:35:08 +0300 Message-ID: <83mvht50qb.fsf@gnu.org> References: <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> <8360ojpndr.fsf@gnu.org> <83shrnm0k1.fsf@gnu.org> <83insi5jy9.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477316147 2048 195.159.176.226 (24 Oct 2016 13:35:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Oct 2016 13:35:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 24 15:35:42 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 1byfPK-0005gY-Fl for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 15:35:18 +0200 Original-Received: from localhost ([::1]:46817 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byfPM-0007YZ-KE for ged-emacs-devel@m.gmane.org; Mon, 24 Oct 2016 09:35:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43248) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byfPG-0007YM-8i for emacs-devel@gnu.org; Mon, 24 Oct 2016 09:35:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1byfPC-00024V-7q for emacs-devel@gnu.org; Mon, 24 Oct 2016 09:35:14 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1byfPC-00024P-4f; Mon, 24 Oct 2016 09:35:10 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2148 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1byfPB-0003b0-FO; Mon, 24 Oct 2016 09:35:09 -0400 In-reply-to: (message from Stefan Monnier on Mon, 24 Oct 2016 09:04:29 -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:208685 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Mon, 24 Oct 2016 09:04:29 -0400 > > > A small price to pay for the advantages, IMO. > > I think some users will run away screaming if Emacs takes a whole second > to start up. It depends. If those users, like me, have hundreds of buffers in their sessions, and use desktop.el to recreate their sessions, they already wait a few seconds for that. And I don't expect the result to be 1 sec, that's is a rounded up value that is already higher than what I saw. > > The most important advantage in my view is that the dumping/loading > > process becomes very simple and understandable even by people with > > minimal knowledge of C subtleties and Emacs internals, > > Yes, the benefits are clear, but the cost is pretty steep. We will have to speed this up, of course. You didn't expect tossing unexec to be an easy job, did you? > I think we could live with a 0.2s startup time, but that's already > a pretty high cost: > - 0.2s feels sluggish when you expect "immediate". > - byte-compilation has historically moved from "do it in a single > session", to "start a separate Emacs session for each file" for good > reasons. A 0.2s startup time imposes either a much slower > byte-compilation, or will compel us to go back to "do it all in > a single session". I think you forget parallelism. We build Emacs with several compilations running in parallel for a long time. And byte-compiling a typical file already takes more than 0.2 sec, sometimes (often?) significantly more, so I don't see a catastrophe yet. > > This would make future maintenance much more robust and reliable, and > > also allow more contributors to work on improving, speeding up, and > > extending the build process. The alternatives all require us to > > depend on a dwindling handful of people, which is a huge disadvantage > > in the long run. > > Maybe there's indeed a lot of speed up still waiting there, and by > reducing loading time of .elc files (and/or allowing more laziness there) > we could bring down the 0.96s to 0.2s *and* speed up other uses at the > same time. That's my hope, yes. E.g., maybe reading the startup.elc file could run in another thread? In any case, I don't think it's right to throw out this idea without trying very hard to make it work, because the benefits are so clear.