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: Tue, 25 Oct 2016 20:05:33 +0300 Message-ID: <838ttcwe8y.fsf@gnu.org> References: <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> <83mvht50qb.fsf@gnu.org> <8c085c3e-361d-7d10-6f34-07c387eb3b43@dancol.org> <83a8dt4u3a.fsf@gnu.org> <83twc0whav.fsf@gnu.org> <02b7c01e-9df1-bde6-9199-1ced140c143e@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1477415233 8596 195.159.176.226 (25 Oct 2016 17:07:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 17:07:13 +0000 (UTC) Cc: p.stephani2@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 19:07: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 1bz5Be-0008Bm-Sp for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 19:06:55 +0200 Original-Received: from localhost ([::1]:56570 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz5Bh-0000cz-8y for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 13:06:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58127) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz5Ah-00008l-0j for emacs-devel@gnu.org; Tue, 25 Oct 2016 13:05:56 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz5Ad-00024x-MD for emacs-devel@gnu.org; Tue, 25 Oct 2016 13:05:54 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46682) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz5Ad-00024t-IE; Tue, 25 Oct 2016 13:05:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1411 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bz5Aa-0003N5-TO; Tue, 25 Oct 2016 13:05:51 -0400 In-reply-to: <02b7c01e-9df1-bde6-9199-1ced140c143e@dancol.org> (message from Daniel Colascione on Tue, 25 Oct 2016 09:14:55 -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:208788 Archived-At: > Cc: p.stephani2@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org > From: Daniel Colascione > Date: Tue, 25 Oct 2016 09:14:55 -0700 > > >> Everyone who's seriously thought about the unexec problem _understands_ > >> the issue. > > > > The important point is that the number of people here who can claim > > such understanding, enough so to fix the issues, is diminishingly > > small, and gets smaller every year. > > There's no demand for more yet. Not true. Demand for this level of expertise is continuous in Emacs, and never dwindles, not for the last 25 years that I'm involved. > There used* to be a lot more (at least > per-capita) stonemasons in historical societies than in today's society. > That doesn't mean we've forgotten how to cut stones, and if there were a > sudden need to do it, more stonemasons would magically appear. I think your optimism is misplaced. I'm old enough to have seen several proficiencies go extinct due to new technology that made them irrelevant. When demand for those forgotten proficiencies came up, people invariably run to the few still around who know how to do that, they don't learn that themselves (and don't even know how). > > Why do you think this will have better performance that reading a > > single .elc file at startup? It's still mainly file I/O and > > processing of the file's contents, just like with byte-compiled files. > > Because a portable dumper can do less, on both file I/O and processing > of the file's contents. There's no lisp evaluation, no slurping a whole > file into memory. Having to read all of Emacs into memory on startup is > a burden even on a fast, modern machine like mine. > > ~/edev/trunk/src > $ sync && sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches' > > ~/edev/trunk/src > $ time pv < emacs >/dev/null > 48.6MiB 0:00:00 [ 455MiB/s] > [=========================================================>] 100% > > > real 0m0.116s Which is definitely comparable with my measurements of loading all of the *.elc files concatenated, which were proclaimed to be "too slow". > > If we have no reason to believe this portable dumper will be > > significantly faster, we should IMO investigate the .elc method first, > > because it's so much simpler, both in its implementation and in future > > maintenance. E.g., adding a new kind of Lisp object to Emacs would > > require corresponding changes in the dumper. > > Adding a new kind of lisp object requires changes throughout core > anyway. The changes in the dumper are _in_addition_ to that. > > Demand paging in an application, and an application such as Emacs on > > top of that, makes little sense to me. > > Why? It's conceptually no different from autoload. The devil is in the details, though. And there are a lot of details in this case that are completely unrelated to the concept. If you don't get them all right, you get a subtly unstable application that will crash randomly in hard to reproduce and debug situations. > > This is the OS business, not > > ours. Using mmap as a fast way to read a file, yes, that's done in > > many applications. But please lets leave demand paging out of our > > scope. > > Emacs isn't just an application. It's a Lisp virtual machine No, it's not. It's an application with a powerful extension language. > (FWIW, mmap isn't a particularly fast way of doing bulk file reads. > That's why GNU grep removed its mmap support.) It was an example of a low-level technique that is sufficiently simple to use, that's all. > > IMO the less we mess with low-level techniques that no other > > applications use the better, both because we have very few people who > > can do that and because doing so runs higher risk of becoming broken > > by future developments in the platforms we deem important. The > > long-term tendency in Emacs development should be to move away from > > such techniques, not to acquire more of them. > > I'm for anything that delivers meaningful performance advantages. IME, that way lies madness. It's the exact opposite of the direction Emacs should evolve if we want to prevent it from becoming a marginal package for a few enthusiasts.