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: Preview: portable dumper Date: Fri, 02 Dec 2016 08:04:46 -0500 Message-ID: References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <8360n6ruzu.fsf@gnu.org> <834m2nplmb.fsf@gnu.org> <83inr2oje6.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1480683906 4769 195.159.176.226 (2 Dec 2016 13:05:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 13:05:06 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 14:04:57 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 1cCnWL-0008TZ-1n for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 14:04:57 +0100 Original-Received: from localhost ([::1]:34455 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCnWN-0004AP-7W for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 08:04:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60383) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCnWH-0004AJ-IR for emacs-devel@gnu.org; Fri, 02 Dec 2016 08:04:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCnWG-000445-QW for emacs-devel@gnu.org; Fri, 02 Dec 2016 08:04:53 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:9009) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCnWD-00041i-0k; Fri, 02 Dec 2016 08:04:49 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CWBgALW9BX/8mTSC1dHAEBBAEBgy0BAQEBAR6ETYVQr3aCA4YWBAICgWk6EwECAQEBAQEBAV4nhGIBAQMBViMFCws0EhQYDSSIVQi8VQEBAQcCJYp9ihwFjx2KPJkNhguQSyABM4RuHoYKAQEB X-IPAS-Result: A0CWBgALW9BX/8mTSC1dHAEBBAEBgy0BAQEBAR6ETYVQr3aCA4YWBAICgWk6EwECAQEBAQEBAV4nhGIBAQMBViMFCws0EhQYDSSIVQi8VQEBAQcCJYp9ihwFjx2KPJkNhguQSyABM4RuHoYKAQEB X-IronPort-AV: E=Sophos;i="5.30,296,1470715200"; d="scan'208";a="281338175" Original-Received: from 45-72-147-201.cpe.teksavvy.com (HELO pastel.home) ([45.72.147.201]) by smtp.teksavvy.com with ESMTP; 02 Dec 2016 08:04:46 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7DE806548D; Fri, 2 Dec 2016 08:04:46 -0500 (EST) In-Reply-To: <83inr2oje6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 02 Dec 2016 09:54:57 +0200") 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:209916 Archived-At: > Granted, the proposed dumper is not very complicated. But it isn't > trivial either. So if we can achieve a similar effect by using the > "normal" loadup code, which is much simpler and doesn't really require > understanding anything new, I think it's more beneficial for the > project's future. Ken worked on speeding up the lread.c code, and it got to be significantly faster, but not fast enough. AFAIK it's got to the point where it's not clear exactly how to speed it up further. Not that it can't be done, but that it's not obvious how, so it's likely going to require some serious rethinking and maybe restructuring/rewrite of the code. Is it going to happen if we don't merge the pdumper? I'm not so sure. The main impetus behind speeding up lread.c is to replace unexec.c, so I agree with you that merging the pdumper might mean that speeding up lread.c will simply never happen. But I think there's also a very serious risk that even without the pdumper, speeding up lread.c will still never happen: I have no intention on working at speeding up lread.c, AFAICT Ken also gave up on it, anyone else? Personally, I think that maybe we should move in the other direction: keep lread.c for "source code" and generalize the pdumper code so it can also be used for the .elc files. Stefan