From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Skipping unexec via a big .elc file Date: Tue, 25 Oct 2016 15:49:28 -0400 Message-ID: References: <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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477425146 32537 195.159.176.226 (25 Oct 2016 19:52:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Oct 2016 19:52:26 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2.50 (gnu/linux) Cc: p.stephani2@gmail.com, Daniel Colascione , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Oct 25 21:52:22 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 1bz7l2-00036g-KO for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 21:51:36 +0200 Original-Received: from localhost ([::1]:57871 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz7l5-00012o-0P for ged-emacs-devel@m.gmane.org; Tue, 25 Oct 2016 15:51:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bz7j4-0000Ry-KP for emacs-devel@gnu.org; Tue, 25 Oct 2016 15:49:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bz7j3-0004Xx-Sf for emacs-devel@gnu.org; Tue, 25 Oct 2016 15:49:34 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:46845) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1bz7iz-0004UF-Va; Tue, 25 Oct 2016 15:49:30 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CQAgALW9BX/1qOs2tdHAEBBAEBgy0BAQEBAR6ETYVQhGWrEYIDhhYEAgKBaTkUAQIBAQEBAQEBXieEYgEBAwFWIxALLQcSFBgNJIhVCLxVAQEBBwIlin2Ef4UAHQEEmVmZDYYLkEseNoRsIIYKAQEB X-IPAS-Result: A0CQAgALW9BX/1qOs2tdHAEBBAEBgy0BAQEBAR6ETYVQhGWrEYIDhhYEAgKBaTkUAQIBAQEBAQEBXieEYgEBAwFWIxALLQcSFBgNJIhVCLxVAQEBBwIlin2Ef4UAHQEEmVmZDYYLkEseNoRsIIYKAQEB X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="277102372" Original-Received: from 107-179-142-90.cpe.teksavvy.com (HELO ceviche.home) ([107.179.142.90]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Oct 2016 15:49:28 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 5A55A66239; Tue, 25 Oct 2016 15:49:28 -0400 (EDT) In-Reply-To: <83twc0whav.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 25 Oct 2016 18:59:36 +0300") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:208801 Archived-At: >> At startup, we'll load the dump file and walk the relocations, fixing up >> all the embedded addresses to account for the new process's different >> address space. > 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. I guess it depends if we can get lread.c to be bound by file-I/O. Currently, it's significantly slower. It's clear on the surface that lread.c has more work to do than an ideal "portable undumper": - the PU just has to find all pointers and increment them by a fixed offset (it could do so either by a GC-like traversal, or by consulting an auxiliary precomputed table of addresses stored alongside the dump state) - lread.c has to check every byte for lexing/parsing, it has to call the memory allocator for every object, tie the knots for cyclic objects, `intern` the symbols, decode the \ in strings, ... The jury is still out whether this extra work can be implemented efficiently enough. There are other differences which can impact the performance (e.g. the size of the "dump" is likely different in the two cases, so the amount of I/O is affected) and the desirability (speeding up loading of .elc would benefit other cases as well, we could generate a generic dump.elc rather than have it be OS-specific, ...) Stefan