From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: Finding the dump Date: Mon, 28 Jan 2019 11:46:19 -0800 Message-ID: References: <83munr8jb1.fsf@gnu.org> <838szb8ey9.fsf@gnu.org> <83d0oj62bc.fsf@gnu.org> <87ef8z4g1m.fsf@igel.home> <838sz75u7p.fsf@gnu.org> <877eer4e4x.fsf@igel.home> <835zub5p3i.fsf@gnu.org> <8736pf408v.fsf@igel.home> <83womq3z5c.fsf@gnu.org> <871s4yxfvb.fsf@igel.home> <83o9823xcq.fsf@gnu.org> <87womqvyy4.fsf@igel.home> <4f30b2b598e71d2c6ad766a3da8e4a33.squirrel@dancol.org> <87o982vszn.fsf@igel.home> <87k1ipx3jq.fsf@igel.home> <87bm41wzmv.fsf@igel.home> <837eep4fkj.fsf@gnu.org> <47a6df84-35b1-a85c-44be-5cec033e9255@cs.ucla.edu> <834l9s4wx4.fsf@gnu.org> <8d219dad-5f90-f231-75c8-04a22db0f36d@dancol.org> <3fe7b1fc-628e-7a2e-c3a9-c80db9a14e39@cs.ucla.edu> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="247974"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Eli Zaretskii , Daniel Colascione , schwab@linux-m68k.org, rpluim@gmail.com, emacs-devel@gnu.org To: "Paul Eggert" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 28 21:04:20 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1goD8i-0012EU-QS for ged-emacs-devel@m.gmane.org; Mon, 28 Jan 2019 21:04:17 +0100 Original-Received: from localhost ([127.0.0.1]:37955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goD8h-0002Vn-Qe for ged-emacs-devel@m.gmane.org; Mon, 28 Jan 2019 15:04:15 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44475) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1goD4e-0007j8-CY for emacs-devel@gnu.org; Mon, 28 Jan 2019 15:00:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1goCrZ-0006ru-BY for emacs-devel@gnu.org; Mon, 28 Jan 2019 14:46:34 -0500 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:58208) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1goCrO-0006Po-Ky; Mon, 28 Jan 2019 14:46:23 -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:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=faa3pgGxhRWgx1w33btxHnkAVcFD4843iU6KkQtok4A=; b=J/D5CScjjo6zKMjQIKMKLZDJU23V3jK42eXfvcauy3drHCIrMGhoG/mE68/T8tMCSiqwJar95fQB79vkpf258Fb4mDunWW9h1vltneF2JHBP9VAsl/lUTQ68ugH1ofFeEjFtnc0a4bItEPpjTn5uRIL7kV3fDfT8v1luT30PhhC76e85YSN8OQrfSOXxMr7rkxJf7ANFM4lrAxQ2H/cmK6KeqZM18W3vSO+Hsu1Y2b+o9OPK1M4rabRoczvhztfJZUC9va3bNukKzRbJgeS2B1wUOLOakTuVCTJKS4HB/eyi/K4ug4iN5ejSXCI2di+XZqtOh3JAOTG51WjID2QgHQ==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1goCrL-0007ec-Cz; Mon, 28 Jan 2019 11:46:19 -0800 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Mon, 28 Jan 2019 11:46:19 -0800 In-Reply-To: <3fe7b1fc-628e-7a2e-c3a9-c80db9a14e39@cs.ucla.edu> X-Priority: 3 (Normal) Importance: Normal 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:232776 Archived-At: > On 1/28/19 8:02 AM, Daniel Colascione wrote: >> The overhead of opening a file in libexec is negligible. > > It's not just opening the file; it's reading the file and eagerly > converting its data to internal format. Data conversion is slow, which is why pdumper doesn't do it. The dump is a memory image, not an elc file. We do need to relocate the dump in order to adjust it for ASLR, but any dumper approach needs to do that, or disable ASLR. I experimented with a non-relocatable, relocation-less mode for pdumper --- just mark Emacs as non-PIC and embed the dump in the emacs data segment, so it's located at a constant address in memory on each run --- but it turns out that relocation is so fast, only 1-2ms, that it's really not worth the trouble. And from a security POV, we shouldn't be encouraging people to disable ASLR. I'm not sure what your proposal is, exactly, or how it would differ from this non-PIC pdumper mode. > Not everybody cares as much about startup latency as I do, and I can > understand it if the issue does not seem that important to others. But > on my platform, Emacs master's startup time is more than twice as long > than (say) Python 3's, and I'd like to see Emacs catching up rather than > falling further behind. One option is to do pdumper relocations on-demand, in a SIGSEGV handler. I actually implemented this approach, and it works fine, but because we have a dumb stop-the-world non-generational GC, we ended up paging in most of the dump on the first GC anyway, so doing relocations on demand doesn't actually help. If we had a generational GC, we could avoid paging in most of the dump, speeding both startup and steady-state performance. But look at it from a different POV: we can make emacs -Q faster, but the performance of emacs -Q doesn't matter for most users. Most user-visible startup latency comes from user customization. The single biggest improvement we can make to observed startup time for typical users is to use pdumper to automatically checkpoint Emacs after user customization and, on subsequent startups, skip all the ~/.emacs work. I explicitly designed pdumper to make this use case possible. This change, along with automatic .elc maintenance, will do more for real-world Emacs performance than GC tweaks or incremental improvements to pdumper load performance.