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: Fri, 2 Dec 2016 12:24:50 -0500 Message-ID: <5B335497-681A-472F-946A-FF518C980695@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> <20C103E2-3F41-4746-A146-61BFE5283D9A@raeburn.org> <83h96moj0n.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 1480699542 3659 195.159.176.226 (2 Dec 2016 17:25:42 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Dec 2016 17:25:42 +0000 (UTC) Cc: jwiegley@gmail.com, dancol@dancol.org, Richard Stallman , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 02 18:25:37 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 1cCraa-0008Un-Bg for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 18:25:36 +0100 Original-Received: from localhost ([::1]:35774 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCrae-0003Re-9q for ged-emacs-devel@m.gmane.org; Fri, 02 Dec 2016 12:25:40 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCrZx-0003QG-0s for emacs-devel@gnu.org; Fri, 02 Dec 2016 12:25:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCrZt-00052f-PQ for emacs-devel@gnu.org; Fri, 02 Dec 2016 12:24:57 -0500 Original-Received: from mail-qt0-x243.google.com ([2607:f8b0:400d:c0d::243]:34969) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cCrZt-00051b-Hb for emacs-devel@gnu.org; Fri, 02 Dec 2016 12:24:53 -0500 Original-Received: by mail-qt0-x243.google.com with SMTP id m48so28261228qta.2 for ; Fri, 02 Dec 2016 09:24:53 -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=L6mjcD1wccktmEBty+g1I29vDp/4ua3NYQBMTPCaf8Q=; b=sTx1bglpZO7rcKS/6q6U6K7VIbH4oDMyhdnaM138THZ5j/wNh3XSifm1BPHLteWSCu 5Z9ScLBqw/Ep6yOOuWv0RXLzT9xqAgSGT/55Rpbl+7xqfZPYUMTKsONvKhxQdOkZ5aE0 rQW3q7wH5svll7eK1NtN7urPDVZQGEP1Bjgo1ACz3VgwIByBgV6UAAszDZvXgQG+aL4R Xzd0NSi2rPCfUll4ux+xclmvyiczGafrnV+moUlPw4zQL9LmoNBRy0FB+aX0+vTtafO8 R48rReLcFt7pJlxpVk4PgJ/dHaiI4qCd5yo9Iy3dil7E0ywwjZnIn1DOcYOGLlAhHN9p XJYg== 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=L6mjcD1wccktmEBty+g1I29vDp/4ua3NYQBMTPCaf8Q=; b=T+/xh0cQFHBoM/DM3v2wQ9J2wWkE9kMS8hQT3bzxlvybZJ1yHM042NnNZ0IZmQsgRz /DQtSz859bSxbXfb13xn5tS7UEjXyfb5woOvuZ4W3hsYW3PcaRwEHUmVwQlWxVuFHFG0 P+DuT+FA5zvt8AE61/UlAlQC4B3VF5kjoe59o3VX0MAvCyoRF6AfR6EzBlrWGzWJWZVj 4YOQ2g/05s1/Hi8VDrCdKmQyJWRdIFAceybnanokxwJLS20x4HHh0Mtbmff5cKOeM4Cy 9vv2gNI+SsLPTVNZ162QmGZb68daNDVSXdvC+RPV2bUgvueXMBGwd0Ph835Vec4rwudv CNHA== X-Gm-Message-State: AKaTC00d+Wb6vabDCC6AFBK/JCV9zWRYAehjrwp4iPHug2gpjOKmYmba9KN/2G86u3C41Q== X-Received: by 10.237.53.56 with SMTP id a53mr38358168qte.85.1480699492343; Fri, 02 Dec 2016 09:24:52 -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 v18sm3021868qkb.40.2016.12.02.09.24.51 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 02 Dec 2016 09:24:51 -0800 (PST) In-Reply-To: <83h96moj0n.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::243 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:209937 Archived-At: On Dec 2, 2016, at 03:03, Eli Zaretskii wrote: >> From: Ken Raeburn >>=20 >> 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. >=20 > 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. Certainly. Some of that code is a bit subtle, and I=E2=80=99d = appreciate the review. > 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/? Not currently. My benchmark has usually been along the lines of: time ./emacs -nw =E2=80=94eval '(progn (sit-for 0.01) (kill-emacs))=E2=80= =99 to initialize everything (including tty display and input checking) and = then quit, in a consistent fashion from run to run. After running it = several times and hopefully seeing fairly consistent numbers after the = first invocation or two, I estimate the average by eye. So, yeah, it = could be more precise. Since we=E2=80=99re timing Emacs startup itself, we can=E2=80=99t test = it with Lisp helper functions invoked once Emacs has started like we = would with many other things. And it=E2=80=99ll be dependent on system = issues, like whether emacs and dumped.elc are in the kernel=E2=80=99s = page cache or not. For simplicity I=E2=80=99ve been testing with the = cache warmed up, because it eliminates the storage system hardware and = OS read-ahead algorithms and such while I focus on the lread.c code, but = in the real world those will sometimes be factors too, and should be = considered. I=E2=80=99ll think about scripting this in some way that may be more = robust, and maybe adding hooks for OS-specific cache flushing and such. Ken=