[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Performance regression on NFS with new manifest version
From: |
Ludovic Courtès |
Subject: |
Re: Performance regression on NFS with new manifest version |
Date: |
Mon, 21 Aug 2017 17:49:43 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) |
Hi,
Roel Janssen <address@hidden> skribis:
> Ricardo Wurmus writes:
>
>> Hi Roel,
>>
>>> Looking into the manifests ($GENERATION_15/manifest and
>>> $GENERATION_16/manifest), I noticed that generation 15 uses manifest
>>> version 2, and generation 16 uses manifest version 3.
>>>
>>> What has changed, so that it takes a lot longer to run the same command
>>> as before? (this is probably disk-related, because that is a known
>>> cause for trouble on network-mounted stores..)
>>
>> Commit 55b4715fd4c03e46501f123c5c9bc6072edf12a4 bumped the manifest
>> version to 3. The goal was to represent propagated inputs as manifest
>> entries so that we can anticipate conflicts from propagated inputs and
>> refuse to build a profile when there would be conflicts.
>
> Thanks for pointing to that commit. It's much better this way. :-)
>
> So, what makes 'guix package --search-paths' so slow? It doesn't have
> to check for conflicts because that's already done on profile creation
> time. All it has to do is combine the search-path data and output
> that..
Could it be that you have lots of propagated inputs in your profile
(Python, etc.)? Are you sure (per ‘strace’) that it has to do with file
system accesses?
That could be a quadratic thing that popped up somewhere in that commit.
Ludo’.