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: Preview: portable dumper Date: Fri, 02 Dec 2016 10:03:04 +0200 Message-ID: <83h96moj0n.fsf@gnu.org> References: <047a67ec-9e29-7e4e-0fb0-24c3e59b5886@dancol.org> <83zikjxt1j.fsf@gnu.org> <727ccd66-3bc3-2a41-7d1d-ef6dae9f0d1e@dancol.org> <7A914757-B1A4-4EEE-9DF0-68EFDDA9A5DB@autodesk.com> <83k2bmxju3.fsf@gnu.org> <837f7mrvq8.fsf@gnu.org> <8337i7plje.fsf@gnu.org> <20C103E2-3F41-4746-A146-61BFE5283D9A@raeburn.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1480665837 13739 195.159.176.226 (2 Dec 2016 08:03:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 08:03:57 +0000 (UTC) Cc: jwiegley@gmail.com, dancol@dancol.org, rms@gnu.org, emacs-devel@gnu.org To: Ken Raeburn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 09:03:52 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 1cCiou-0002H3-Hn for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 09:03:48 +0100 Original-Received: from localhost ([::1]:33098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCiow-0005uR-EH for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 03:03:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45035) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCioF-0005uB-Ac for emacs-devel@gnu.org; Fri, 02 Dec 2016 03:03:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCioC-000225-8k for emacs-devel@gnu.org; Fri, 02 Dec 2016 03:03:07 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:36826) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCioC-000221-5n; Fri, 02 Dec 2016 03:03:04 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1198 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cCio3-0003sa-Jg; Fri, 02 Dec 2016 03:02:56 -0500 In-reply-to: <20C103E2-3F41-4746-A146-61BFE5283D9A@raeburn.org> (message from Ken Raeburn on Thu, 1 Dec 2016 23:28:27 -0500) 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:209906 Archived-At: > From: Ken Raeburn > Date: Thu, 1 Dec 2016 23:28:27 -0500 > Cc: rms@gnu.org, > dancol@dancol.org, > jwiegley@gmail.com, > emacs-devel@gnu.org > > > Ken, will you be able to continue working on your branch in this > > direction? Are all the changes suggested/tried by Stefan already on > > that branch? If not, would it be possible for Stefan or yourself to > > update the branch? > > I have an update I’m still working on, to refine the hash table handling I did to generate less garbage while reading normal .el or .elc files. I hope to get that uploaded soon. And I think my previous push of the branch was before Stefan’s latest patch (Oct 31?), so I’ll pull that in too, unless he’s done some more work since. Thanks. > Regardless of the outcome of this current disagreement and whether big-elc gets used, I think the lread changes may soon be ready to merge, even if the performance benefits are less drastic for normal Lisp code. I agree in general, but let's discuss this again when you think the branch is ready. I'd like to have the branch reviewed by those who are interested (I will certainly do that myself) before we merge. Does the branch include any benchmarks, to compare performance with the current code, both for dumped.elc and for normal Lisp code? If not, can they be included/added, perhaps under test/? > As for non-performance issues, last time I tried the big-elc code, it didn’t work for me in batch mode because of a null pointer dereference in face processing; I haven’t had a chance to look into it further but maybe in the next few days I can. Let me know if you need help in that department. Thanks again for working on this.