Duy Nguyen <pclouds@xxxxxxxxx> writes:
> On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares
> <matheus.bernardino@xxxxxx> wrote:
>> I downloaded chromium to give it a try and got (on a machine with i7 and
>> SSD, running Manjaro Linux):
>>
>> - 17s on blame for a file with long history[2]
>> - 2m on blame for a huge file[3]
>> - 15s on log for both [2] and [3]
>> - 1s for git status
>>
>> It seems quite a lot, especially with SSD, IMO.
>
> There have been a couple of optimizations that are probably still not
> enabled by default because they only benefit large repos.
I've proposed a trivial change in 2014 that could have cut down typical
blame times significantly but nobody was interested in testing and
committing it, and it is conceivable that in limited-memory situations
it might warrant some accounting/mitigation for weird histories (not
that there isn't other code like that).
Rebased/appended.
--
David Kastrup
>From a076daf13d144cb74ae5fd7250445bbfb4669a05 Mon Sep 17 00:00:00 2001
From: David Kastrup <dak@xxxxxxx>
Date: Sun, 2 Feb 2014 18:33:35 +0100
Subject: [PATCH] blame.c: don't drop origin blobs as eagerly
When a parent blob already has chunks queued up for blaming, dropping
the blob at the end of one blame step will cause it to get reloaded
right away, doubling the amount of I/O and unpacking when processing a
linear history.
Keeping such parent blobs in memory seems like a reasonable optimization
that should incur additional memory pressure mostly when processing the
merges from old branches.
---
blame.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/blame.c b/blame.c
index 5c07dec190..c11c516921 100644
--- a/blame.c
+++ b/blame.c
@@ -1562,7 +1562,8 @@ static void pass_blame(struct blame_scoreboard *sb, struct blame_origin *origin,
}
for (i = 0; i < num_sg; i++) {
if (sg_origin[i]) {
- drop_origin_blob(sg_origin[i]);
+ if (!sg_origin[i]->suspects)
+ drop_origin_blob(sg_origin[i]);
blame_origin_decref(sg_origin[i]);
}
}
--
2.20.1
