[darcs-users] [patch127] Re: patches to Darcs.Commands.ShowFiles, and repository internals

[Thomas Hartman]

Thomas Hartman <thomashartman1 at googlemail.com> added the comment:

What and where are the  CLONE_FS (...) flags ?

...darcs.net $ find -type d -name _darcs -prune -o -name *.hs -print |
xargs -i grep CLONE {} # (no output)



2010/1/11 Petr Ročkai <bugs at darcs.net>:
>
> Petr Ročkai <me at mornfall.net> added the comment:
>
> Hi,
>
> Ganesh Sittampalam <bugs at darcs.net> writes:
>
>>> [make slurpPristine use absolute paths (no more need to wrap in
>> getCurrrentDirectory/withCurrentDirectory)
>>> thomashartman1 at gmail.com**20100102175426
>>>  Ignore-this: 9e0d47590c4b92d9c6c774730136113e
>>> ]
>>
>> I'm not convinced this patch is correct, since mmap_slurp itself looks at the
>> current directory. I definitely support the intention though. Could you provide
>> more justification of why it's ok?
>
> One more thing to keep in mind with this kind of patches is that
> handling absolute paths (and probably more so with FilePath/String-based
> paths) could be potentially much more expensive than handling relative
> paths. Path manipulation is a nontrivial portion of the darcs processing
> time and doing this kind of change could slow down things across the
> board.
>
> In a repository that lives at 40-character deep absolute path, with
> 10000 files, the path operations done for pristine need to churn over 3
> megabytes extra of the common prefixes (10000 * 40 * 8 -- assuming 8
> bytes per String element). If the paths are stored (not sure right now),
> the prefixes cannot be shared due to nature of Haskell lists.
>
> Moreover, the index stores relative paths, since the repository root can
> relocate. If we required absolute paths to be used in stat/open calls,
> this would force darcs to copy each path out of the mmap'd index into
> the heap, concatenating it with current path, again an operation that is
> not completely free (the ability to pass pointers into the mmap area
> without further manipulation directly to stat proved to be an important
> optimisation).
>
> I would say that if you are running on Linux, the right answer to your
> problem is omitting CLONE_FS from the clone(...) flags (which makes the
> threads to have their own working directory). I am not sure this is
> achievable through the pthread interface, though.
>
> Yours,
>   Petr.
>
> ----------
> nosy: +mornfall
>
> __________________________________
> Darcs bug tracker <bugs at darcs.net>
> <http://bugs.darcs.net/patch127>
> __________________________________
> _______________________________________________
> darcs-users mailing list
> darcs-users at darcs.net
> http://lists.osuosl.org/mailman/listinfo/darcs-users
>

__________________________________
Darcs bug tracker <bugs at darcs.net>
<http://bugs.darcs.net/patch127>
__________________________________