From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Newsgroups: gmane.lisp.guile.bugs Subject: bug#19540: repeated ./././ in compiled modules Date: Fri, 24 Jun 2016 11:41:06 +0200 Message-ID: <87inwy9b65.fsf@gnu.org> References: <188846A3-246A-49DB-95F0-37FEE6903C85@alumni.caltech.edu> <877fwiy0q2.fsf@gnu.org> <093940B7-4480-4FD4-A0AD-0B19B6FEECDB@alumni.caltech.edu> <87iog117is.fsf@gnu.org> <871t3oqp2e.fsf@pobox.com> <87k2hgoy0c.fsf@gnu.org> <87fus3opto.fsf@pobox.com> <87twgj9eiu.fsf@gnu.org> <87fus3geev.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1466761355 15744 80.91.229.3 (24 Jun 2016 09:42:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 24 Jun 2016 09:42:35 +0000 (UTC) Cc: 19540-done@debbugs.gnu.org, Matt Wette To: Andy Wingo Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Jun 24 11:42:25 2016 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1bGNcy-0002Bk-N3 for guile-bugs@m.gmane.org; Fri, 24 Jun 2016 11:42:20 +0200 Original-Received: from localhost ([::1]:42198 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGNcs-0003As-R4 for guile-bugs@m.gmane.org; Fri, 24 Jun 2016 05:42:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56521) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGNck-00038V-EQ for bug-guile@gnu.org; Fri, 24 Jun 2016 05:42:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGNcg-0000VD-FY for bug-guile@gnu.org; Fri, 24 Jun 2016 05:42:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:41094) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGNcg-0000V9-CI for bug-guile@gnu.org; Fri, 24 Jun 2016 05:42:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bGNcg-0003s7-5e for bug-guile@gnu.org; Fri, 24 Jun 2016 05:42:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 24 Jun 2016 09:42:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 19540 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 19540-done@debbugs.gnu.org id=D19540.146676128214827 (code D ref 19540); Fri, 24 Jun 2016 09:42:02 +0000 Original-Received: (at 19540-done) by debbugs.gnu.org; 24 Jun 2016 09:41:22 +0000 Original-Received: from localhost ([127.0.0.1]:53431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGNc1-0003r3-S3 for submit@debbugs.gnu.org; Fri, 24 Jun 2016 05:41:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:37187) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bGNc0-0003qn-KL for 19540-done@debbugs.gnu.org; Fri, 24 Jun 2016 05:41:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bGNbr-0000MN-6H for 19540-done@debbugs.gnu.org; Fri, 24 Jun 2016 05:41:15 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56004) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bGNbr-0000Ll-3I; Fri, 24 Jun 2016 05:41:11 -0400 Original-Received: from pluto.bordeaux.inria.fr ([193.50.110.57]:48156 helo=pluto) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bGNbp-0008TK-0R; Fri, 24 Jun 2016 05:41:09 -0400 X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 7 Messidor an 224 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0x090B11993D9AEBB5 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 3CE4 6455 8A84 FDC6 9DB4 0CFB 090B 1199 3D9A EBB5 X-OS: x86_64-unknown-linux-gnu In-Reply-To: <87fus3geev.fsf@pobox.com> (Andy Wingo's message of "Fri, 24 Jun 2016 10:49:12 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:8217 Archived-At: Andy Wingo skribis: > On Fri 24 Jun 2016 10:28, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Hello! >> >> Andy Wingo skribis: >> >>> On Thu 23 Jun 2016 15:06, ludo@gnu.org (Ludovic Court=C3=A8s) writes: >>> >>>> =E2=80=98canonicalize_file_name=E2=80=99 is costly: roughly one syscal= l per file name >>>> component. >>>> >>>> IIUC, =E2=80=98canonicalize_file_name=E2=80=99 is now called once for = each =E2=80=98%load-path=E2=80=99 >>>> entry and file name that we canonicalize. Is this correct? >>> >>> That's correct, but only for relative canonicalization, which is in >>> practive only when loading Scheme files from source. Seems out of the >>> hot path; what do you think? >> >> I think it=E2=80=99s likely to have a noticeable impact on startup time = for >> projects with a large number of modules like Guix. > > Aren't they usually compiled? Loading compiled files will not > go through this path AFAIU. Good point, I had overlooked that. >> For instance, commands like =E2=80=98guix package -A=E2=80=99 or =E2=80= =98guix build foo=E2=80=99 load >> all the modules. The impact will be smaller on a laptop with an SSD >> than on an NFS mount, where it=E2=80=99s likely going to be terrrible (t= his >> could be tested using the =E2=80=98delay=E2=80=99 device mapper.) > > Oh I'm with you that we need to be careful here. I am under the > impression though that there's no additional impact here because this is > just something that happens at compile-time. Or if you load a source > file, but in that case you're evaluating and expecting a perf loss is > not the end of the world. Indeed, this makes sense to me now; sorry for the confusion! Ludo=E2=80=99.