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: pdumper's performance Date: Wed, 29 Aug 2018 15:10:24 -0700 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1535581385 29976 195.159.176.226 (29 Aug 2018 22:23:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 29 Aug 2018 22:23:05 +0000 (UTC) User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , emacs-devel@gnu.org To: "Stefan Monnier" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 30 00:23:01 2018 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 1fv8ra-0007ec-5I for ged-emacs-devel@m.gmane.org; Thu, 30 Aug 2018 00:22:58 +0200 Original-Received: from localhost ([::1]:45205 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv8tg-0005T0-9o for ged-emacs-devel@m.gmane.org; Wed, 29 Aug 2018 18:25:08 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54075) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fv8tL-0005KX-7I for emacs-devel@gnu.org; Wed, 29 Aug 2018 18:24:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fv8fb-0001q5-Ik for emacs-devel@gnu.org; Wed, 29 Aug 2018 18:10:37 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:40020) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1fv8fb-0001lq-3K for emacs-devel@gnu.org; Wed, 29 Aug 2018 18:10:35 -0400 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=78BURIZwalFvSEz8lp0QwYdyrx6ACR3rgSUAUWi8QvA=; b=qg/kser0Gk+/OIAdOs6CJm96kqyVtPYK6LEyUmSHoQ0rMjoXpN281A9DV8t0ZjX5IETO1CNK4UQQ+vyNLncG1R2Fhdj2slZ91/R4g9xGaDPCzurrlBt64r4BWM+ES7SsIx4kdE8NpFQ5ruRfgCbdjT1iC1FloajldZ9rmqk3kT+jLO10EWpm4mZ+l3exHqvlA+0tcY7bpphcOc+mjdI5R5kma7e4EUWrbxhQStGYacXztRMukJdqfZyTU58gUZbG28eGdRuGxbkzcn7Ezspm41NmqJjN4VSIQs7G7vFW0/iSWBLL7yOrtxWodXFyQ3aOvFX6PUeNyEuKHn/N8H8WvQ==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fv8fQ-0000hF-JS; Wed, 29 Aug 2018 15:10:24 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Wed, 29 Aug 2018 15:10:24 -0700 In-Reply-To: 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:229073 Archived-At: > I was looking at the pdumper and one thing I was wondering is how to use > of all the _marked_p and set__marked functions impacts GC (and > hence) runtime performance. > > I mean the fact that they're functions is perfectly fine, but the fact > that they need to test pdumper_object_p might have a measurable impact, > since I believe these operations are performed very many times per GC. The cache line that holds that the dump region bounds ends up being very hot, so testing it isn't really that expensive. You can see for yourself whether there's an impact. Compile an Emacs with support for both pdumper and unexec, dump it with unexec, and compare its GC performance to Emacs built without support for pdumper and also dumped with unexec. As I recall, the difference is minimal. Besides, you get performance back at the end: the dump region's mark bits are stored contiguously and we can clear them very quickly at the end of GC. > Also I don't quite understand why this is needed: IIUC the markbits of > pdump'd objects are stored elsewhere, but I don't understand why that > needs to be the case. Because we don't store dumped objects in blocks and so the calculations of the normal locations of their mark bits would be wrong.