[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#19540: repeated ./././ in compiled modules
From: |
Ludovic Courtès |
Subject: |
bug#19540: repeated ./././ in compiled modules |
Date: |
Fri, 24 Jun 2016 10:28:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) |
Hello!
Andy Wingo <address@hidden> skribis:
> On Thu 23 Jun 2016 15:06, address@hidden (Ludovic Courtès) writes:
>
>> Andy Wingo <address@hidden> skribis:
>>
>>> commit 9a951678713557b548415d32eae6d63d039bf652
>>> Author: Andy Wingo <address@hidden>
>>> Date: Thu Jun 23 10:03:10 2016 +0200
>>>
>>> Fix relative file name canonicalization on paths with "."
>>>
>>> * libguile/filesys.c (scm_i_relativize_path): Canonicalize the file
>>> names elements that we will be using as prefixes. Fixes the case
>>> where a load path contains a relative file name: #19540.
>>> * test-suite/tests/ports.test ("%file-port-name-canonicalization"): Add
>>> tests that elements of the load path are canonicalized.
>>>
>> ‘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.
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.)
WDYT?
Ludo’.