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: Thu, 1 Dec 2016 20:41:47 -0800 Message-ID: <9b1a595e-92a6-80ed-10ab-0ea2741ba4a0@dancol.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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1480653761 10194 195.159.176.226 (2 Dec 2016 04:42:41 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 04:42:41 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 Cc: jwiegley@gmail.com, rms@gnu.org, emacs-devel@gnu.org To: Ken Raeburn , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 05:42:35 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 1cCfgA-00016V-1l for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 05:42:34 +0100 Original-Received: from localhost ([::1]:60579 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCfgA-0004k7-R1 for ged-emacs-devel@m.gmane.org; Thu, 01 Dec 2016 23:42:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36399) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCffc-0004iR-Ba for emacs-devel@gnu.org; Thu, 01 Dec 2016 23:42:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCffZ-0003E3-9O for emacs-devel@gnu.org; Thu, 01 Dec 2016 23:42:00 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40936) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCffZ-0003D8-0i; Thu, 01 Dec 2016 23:41:57 -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:Cc:References:To:Subject; bh=ZS2xumpYxi6OmUbzegJaqvDiDa2ghT6RwlEhE0sRpyk=; b=eXOL92HxAifVbtKsnk5U+eLgxPMh0FegkZvpJTovX6hBOkxrgqr9TMlGktyIUosXATE1LMk4se01kMk0hA9NuLomFrHv/R0ed3gE3RzGgHof/lMnIRb7PNsFPgAUEUHi2pNsOGU+9Aq1JAkPxQA2gb9Uvf7xzbBurdJ2UbW2VD5JE0vaQUey59mG/JTQI6EyydgCXECAw827s8nf0zbAvbSXIeyPOxFFsLdRJRnpIYXKIHPy+RtcTITDH32xJWf/ugMVquX5/LgkRc8imlM6ik21E7QYcM3QuelHCWI1TEkfHR9h7pnl3XbOMg7W9oaBcBsuE1EHzvc/hC17rRwLhw==; 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 1cCffV-0001Ew-2W; Thu, 01 Dec 2016 20:41:53 -0800 In-Reply-To: <20C103E2-3F41-4746-A146-61BFE5283D9A@raeburn.org> 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:209901 Archived-At: On 12/01/2016 08:28 PM, Ken Raeburn wrote: > >> On Dec 1, 2016, at 13:11, Eli Zaretskii wrote: >> >>> 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 >>> >>> 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. >> >> Agreed. >> >> 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. > > My focus has been on the dumped.elc load performance; the content generation has been pretty much all his work. > > Stefan’s work on reducing “#n#” 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’s code addresses the cons cells, and for property-less strings (and certain other types) the substitution pass isn’t needed, so I think we’ve 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’ve 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’t actually wind up needing the hash tables. > Of course all of this work isn't in C and doesn't require specialized skills, right? > 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. Yes, elc loading performance is welcome regardless.