GNU bug report logs - #19540
minor: module path picking up ./././...

Previous Next

Full log

Message #40 received at 19540-done <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: Andy Wingo <wingo <at> pobox.com>
Cc: 19540-done <at> debbugs.gnu.org, Matt Wette <mwette <at> alumni.caltech.edu>
Subject: Re: bug#19540: repeated ./././ in compiled modules
Date: Fri, 24 Jun 2016 11:41:06 +0200

Andy Wingo <wingo <at> pobox.com> skribis:

> On Fri 24 Jun 2016 10:28, ludo <at> gnu.org (Ludovic Courtès) writes:
>
>> Hello!
>>
>> Andy Wingo <wingo <at> pobox.com> skribis:
>>
>>> On Thu 23 Jun 2016 15:06, ludo <at> gnu.org (Ludovic Courtès) writes:
>>>
>>>> ‘canonicalize_file_name’ is costly: roughly one syscall per file name
>>>> component.
>>>>
>>>> IIUC, ‘canonicalize_file_name’ is now called once for each ‘%load-path’
>>>> 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’s 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 ‘guix package -A’ or ‘guix build foo’ load
>> all the modules.  The impact will be smaller on a laptop with an SSD
>> than on an NFS mount, where it’s likely going to be terrrible (this
>> could be tested using the ‘delay’ 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.