From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Thu, 1 Dec 2016 23:28:27 -0500 Message-ID: <20C103E2-3F41-4746-A146-61BFE5283D9A@raeburn.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1480652952 30891 195.159.176.226 (2 Dec 2016 04:29:12 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 04:29:12 +0000 (UTC) Cc: jwiegley@gmail.com, dancol@dancol.org, rms@gnu.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 05:29:04 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 1cCfT6-0006xP-4I for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 05:29:04 +0100 Original-Received: from localhost ([::1]:60550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCfT9-0002m9-JJ for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 23:29:07 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59932) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCfSd-0002ls-Bj for emacs-devel@gnu.org; Thu, 01 Dec 2016 23:28:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCfSa-0004Sb-8N for emacs-devel@gnu.org; Thu, 01 Dec 2016 23:28:35 -0500 Original-Received: from mail-qt0-x244.google.com ([2607:f8b0:400d:c0d::244]:33459) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCfSa-0004SG-2V for emacs-devel@gnu.org; Thu, 01 Dec 2016 23:28:32 -0500 Original-Received: by mail-qt0-x244.google.com with SMTP id n6so26168130qtd.0 for ; Thu, 01 Dec 2016 20:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raeburn-org.20150623.gappssmtp.com; s=20150623; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oitq/6YRk9oWiaGiyUEx3c+P7HyZ7LmQREcBgk25oek=; b=e70/3TEcpzQheTwgGC2IkqJ+Dr4Av996l5O/rFD6doXnbm5Wvn4gZNCt6SUwy6qtFb sT7EbpMWgIMtg8N2ome6u9ecCFIx/YLmXnaxylbtANpv9PRsaNp0qGyij5+6350DUq25 gnMR++QZmklBtU5n2WY5tpdwPpHOvztUJP6J1kVgTx0/rnmPgzo9VPBh9r1yBEkfDIuz AvuZ0rAdwb/floCeVDWnlPX9JJaQOjQRvLsAMMXrXO1uxV/IS3gPV69E7uvrj/in1UNR 9El7OEyQr3334VjIjWsMyQtV3lXRmwE4a5OjznYRVjeFqsarLaBSP1X21D+bJ6p8WAhi f+Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=oitq/6YRk9oWiaGiyUEx3c+P7HyZ7LmQREcBgk25oek=; b=HtzWBtU547TPpW5E9n0O7vKBWCnUjWTHvf/9RzryiU6W/W8rPtDfxh0sN71tT6z4yz CwsWA+Gr73xp9MeSct3pRlqHhSirqaQxraQJRzxos/nG8C1bGfQ4nsYPPDfLsaqF2cdF 8QxhPQpZK4i36kAeDjNg/rlTZXGPFVq2VNEa2ljbcbz74BMqupBM//relUZPvRh+hv6r hd96IlVvgUgXGDfqNu98g7MecyD3nMsYeJElnM7wHvMZaBmUZnNLOUNMYSLvwWjCgSqS wYNdymiFGOtuQbciM3XxcU9DlqTV+LWM8Tq/3nuISVYZDfAkf3s2ywog5rihk2Py/Os4 YrPw== X-Gm-Message-State: AKaTC01iImcBO9R6UhKF9n6NQdlrT2A0ljpzNPVqBcl2kTpVXA4jXPZ+WTDJueKGThg3AQ== X-Received: by 10.200.41.171 with SMTP id 40mr40421605qts.235.1480652911167; Thu, 01 Dec 2016 20:28:31 -0800 (PST) Original-Received: from [192.168.23.52] (c-50-138-183-136.hsd1.ma.comcast.net. [50.138.183.136]) by smtp.gmail.com with ESMTPSA id g13sm1764873qtg.15.2016.12.01.20.28.29 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Dec 2016 20:28:30 -0800 (PST) In-Reply-To: <8337i7plje.fsf@gnu.org> X-Mailer: Apple Mail (2.3124) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:400d:c0d::244 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:209900 Archived-At: > On Dec 1, 2016, at 13:11, Eli Zaretskii wrote: >=20 >> From: Richard Stallman >> CC: eliz@gnu.org, jwiegley@gmail.com, burton.samograd@autodesk.com, >> emacs-devel@gnu.org >> Date: Thu, 01 Dec 2016 04:18:04 -0500 >>=20 >> Rather than arguing theoretically about speculations, >> let's see people do their best to improve the big-elc-file >> approach, and then compare facts with facts. >=20 > Agreed. >=20 > 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=E2=80=99m 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=E2=80=99s latest patch (Oct 31?), so = I=E2=80=99ll pull that in too, unless he=E2=80=99s done some more work = since. My focus has been on the dumped.elc load performance; the content = generation has been pretty much all his work. Stefan=E2=80=99s work on reducing =E2=80=9C#n#=E2=80=9D placeholder = substitutions tackled the particular case of cons cells, and he = suggested extending it to other types, but based on some stats I got = looking over the big .elc file, I think cons cells and strings are the = majority of the cases. Stefan=E2=80=99s code addresses the cons cells, = and for property-less strings (and certain other types) the substitution = pass isn=E2=80=99t needed, so I think we=E2=80=99ve addressed the = biggest gains to be had in that area. The patch I made to use a pair of hash tables for tracking previously = read objects seems to have improved performance as well, but I=E2=80=99ve = started to refine it a bit to not create a new pair of hash tables for = every top-level read done, when the majority of the calls (over 95% = during a loadup.el pass I instrumented) don=E2=80=99t actually wind up = needing the hash tables. 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. As for non-performance issues, last time I tried the big-elc code, it = didn=E2=80=99t work for me in batch mode because of a null pointer = dereference in face processing; I haven=E2=80=99t had a chance to look = into it further but maybe in the next few days I can. Ken=