Re: Performance regression on NFS with new manifest version

[Roel Janssen]

Ludovic Courtès writes:

> 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?

Yes, I have lots of propagated inputs in that profile (R packages..).

I haven't checked with strace, but everything else on this machine is
fast and plenty (24 cores, 128GB ram).  The only troublesome thing is
the NFS-mounted store.

>
> That could be a quadratic thing that popped up somewhere in that commit.
>
> Ludo’.

Thanks for looking at this message.

Kind regards,
Roel Janssen