monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: How to determine if a file is version controlled?


From: Bruce Stephens
Subject: [Monotone-devel] Re: How to determine if a file is version controlled?
Date: Thu, 13 Apr 2006 11:19:04 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Wim Oudshoorn <address@hidden> writes:

> Bruce Stephens <address@hidden> writes:

[...]

>> I wonder why it's slow.  
>>
>> I mean, it's inevitably going to be slower than one would like,
>> because monotone is a big program, and probably does a fair bit of
>> work regardless of what you want.  But it probably ought just to be
>> getting the current manifest and looking for the name in that, so that
>> shouldn't be *that* costly, even though it's probably building up lots
>> of data structures that aren't necessary for this specific operation.
>
> I don't know why it is slow, but
>
> $ time monotone ls known Monotone.pm
>
>     Monotone.pm
>
>     real    0m2.745s
>     user    0m1.845s
>     sys     0m0.083s
>
>
> So it takes more than 2 seconds for a specific file in the root of 
> the project.
> This is done with a hot cache, that is, I ran the above 3 times
> in a row and took the last output.

I get similar results:

% time monotone ls known COPYRIGHT
COPYRIGHT
monotone ls known COPYRIGHT  2.28s user 0.01s system 100% cpu 2.292 total

This is for a branch with 30415 files, but the machine's probably
faster.  Doing the same sort of thing for the net.venge.monotone
branch is *much* faster.

I speculate (without looking at the code, or profiling) that
monotone's building up some kind of structure representing the whole
of the manifest, so the time's at least linear in the size (and
possibly a little worse, if it uses a std::map or something).  Too
slow for this specific use, anyway.

If there were an automate version of ls known (whether "automate
inventory" or "automate status" or something else), then you could run
it in "automate stdio", starting that the first time you needed it,
and that would probably work OK.  Doesn't really fit vc-mtn that well,
I guess: you want to know when it's safe to close the process, too.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]