On Sun, Mar 8, 2009 at 2:40 PM, Derek Scherger
<address@hidden> wrote:
that's just a guess and I need to dig into it further. Not sure when I'll get to that. I did try a similar change to mtn log which should be suffering from the same problem but it didn't make much difference there.
Apparently that test was bogus. Unpatched current mainline log:
Sun Mar 08 02:27 PM ~/monotone/mainline $ time ./mtn log > /dev/null
real 5m50.997s
user 4m46.206s
sys 1m4.668s
With the following patch applied:
--- cmd_diff_log.cc 5e5c21fdce653b9ed94bf91aa5c3a5dc3c9478aa
+++ cmd_diff_log.cc b7868316d0e5e475e2a9a49038fee64dda8a4646
@@ -594,10 +594,13 @@ log_certs(project_t & project, ostream &
if (multiline)
newline = true;
- project.get_revision_certs_by_name(id, name, certs);
+ project.get_revision_certs(id, certs);
for (vector<cert>::const_iterator i = certs.begin();
i != certs.end(); ++i)
{
+ if (i->name != name)
+ continue;
+
if (first)
os << label;
else
Sun Mar 08 02:41 PM ~/monotone/mainline $ time ./mtn log > /dev/null
real 0m6.094s
user 0m5.460s
sys 0m0.616s
So log spends almost all of its time loading certs too. I'm now a bit reluctant to apply Felipe's patch and the one above and I'd rather find and fix the problem or delete the offending api altogether.
Cheers,
Derek