From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: When should ralloc.c be used? Date: Sat, 29 Oct 2016 10:55:20 -0400 Message-ID: References: <871szqwu51.fsf@users.sourceforge.net> <831szqhbc2.fsf@gnu.org> <87d1itt79z.fsf_-_@users.sourceforge.net> <7baa18d4-2b09-caa8-005e-29008a383ad1@cs.ucla.edu> <83mvhwrgd5.fsf@gnu.org> <8539f38f-9a11-44c3-4de7-bb974c96206c@cs.ucla.edu> <83d1iq5ib1.fsf@gnu.org> <83r3753c8j.fsf@gnu.org> <83r374wh32.fsf@gnu.org> <83wpgtrmt2.fsf@gnu.org> <83twbvr78y.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1477752986 28451 195.159.176.226 (29 Oct 2016 14:56:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 29 Oct 2016 14:56:26 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 29 16:56:23 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 1c0V32-0003bL-1c for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 16:55:52 +0200 Original-Received: from localhost ([::1]:54900 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0V34-000709-J2 for ged-emacs-devel@m.gmane.org; Sat, 29 Oct 2016 10:55:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49479) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c0V2y-0006zr-6E for emacs-devel@gnu.org; Sat, 29 Oct 2016 10:55:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c0V2v-00076q-32 for emacs-devel@gnu.org; Sat, 29 Oct 2016 10:55:48 -0400 Original-Received: from [195.159.176.226] (port=43493 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1c0V2u-00076h-T9 for emacs-devel@gnu.org; Sat, 29 Oct 2016 10:55:45 -0400 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1c0V2j-0001Mw-NO for emacs-devel@gnu.org; Sat, 29 Oct 2016 16:55:33 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 30 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:4NKH3mmZ9rVn/rfcMbbPKar2idU= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 195.159.176.226 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:208959 Archived-At: > E.g., it turned out that most of the time it takes 'loadup' to do its > job is due to the linear search of pure strings in > find_string_data_in_pure, called by make_pure_string. Indeed. hash-consing pure objects takes another very significant percentage of the time. > If we call 'loadup' upon every startup, the need for pure storage goes > away, and the 'loadup' time can be sped up tenfold. Actually, there's no *need* for pure storage in either case. There are benefits to the use of pure storage, and some of them remain even if we don't dump: one of the benefits that remains is to reduce the size of the GC'd heap and hence speed up the GC. Whether that's significant enough to bother with it is of course debatable. But note also that we could keep the use of pure-space without paying the hefty price of find_string_data_in_pure (or hash-consing), since these merely try to make the purespace more compact. The extra cost is OK when we dump the result, but it's not worth the trouble if we don't dump. > And that is even before making all of the preloaded files a single > file, which speeds up things at least twofold more, according to > my measurements. BTW, how large is that single file (I'm curious if its size is significantly different from the 3.2MB I got for my dumped.elc)? Stefan