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: Preview: portable dumper Date: Mon, 28 Nov 2016 12:31:39 -0800 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <727ccd66-3bc3-2a41-7d1d-ef6dae9f0d1e@dancol.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 1480365205 31956 195.159.176.226 (28 Nov 2016 20:33:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 28 Nov 2016 20:33:25 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 To: Eli Zaretskii , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 28 21:33:21 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 1cBSc4-0007MT-Sp for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 21:33:21 +0100 Original-Received: from localhost ([::1]:32918 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSc8-0004cW-Mo for ged-emacs-devel@m.gmane.org; Mon, 28 Nov 2016 15:33:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45513) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cBSad-00041E-KQ for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:31:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cBSaY-00085n-MO for emacs-devel@gnu.org; Mon, 28 Nov 2016 15:31:51 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:37942) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cBSaY-00085H-96; Mon, 28 Nov 2016 15:31:46 -0500 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:References:To:Subject; bh=nOjYbWdqbT/EXzXc9GzA1DD7jxXC8f3z5/EZ8miLY2g=; b=Ja8dhCR5vcVfdNonjwO/kYqR7upw3BPnbNo1XH2KPjkzL32M6G1+/1pRFVjo3gxr99loOutPTrsxetb1q24NJZUTjbta56q1ONNOaZTahZNQDqXnLDqFUGkAwPwYgsYAjLXGg0fVndBJ9b5IKti0b0fnFkAQOCY4qDOXpo+PGixNBD/rtyjDsGzW5FoYIbF+USPcidTufQ5qzf1OTdcMW0zC3hPzZpCp7bps6k2x5jyXqN4wHH726Xyw0GIY/Y40+VLdb13E5vf/WalLp7okEUGqFR7PMdMTSdZUrvZayu3Dporo2h/ZEB6LfqnDjt0em23BAjj51YppI3CXBQ14Og==; Original-Received: from c-73-140-245-253.hsd1.wa.comcast.net ([73.140.245.253] 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 1cBSaX-0008LP-9P; Mon, 28 Nov 2016 12:31:45 -0800 In-Reply-To: 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:209693 Archived-At: On 11/28/2016 12:26 PM, John Wiegley wrote: >>>>>> "DC" == Daniel Colascione writes: > > DC> Yes --- one that *we* control, which frees us from changes to underlying > DC> systems. Yes, the thing has intimate knowledge of Lisp_Object internals, > DC> but whoever changes those internals (and these changes are rare) can > DC> change the dumper too. > > Then the difference between .elc and this new -- .eld? -- would be exactly > what? Relocation information to speed up load time? > > I'm just wondering: if it's strictly a speed gain, then is there any other way > to achieve it; if it's a functionality gain, what are the advantages over just > speeding up .elc loading. The dump can be used as-is without preparation, particularly if it loads at its desired base address. Reading an ELC requires lots of parsing, interning, and allocation of various sorts. It also prohibits any kind of data sharing between differences instances of Emacs on the same system, while I expect about a third to half of these dumps to be shared. It's also possible to dump arbitrarily already-loaded Emacs processes, which you don't get with a merged ELC, so that's a functionality difference. If Lisp layout changes in the future, it's very easy to adjust pdumper to match. It's really not a big maintenance burden; read the code. > Thanks for doing this work, btw!! The value of your exploration is not lost on > me, since you've now made a concrete alternative for us to consider. If the > differences in approach are small enough, there's no reason we can't change > our minds yet again in the future. This is a purely internal matter, after > all. Are you rejecting the patch?