threads / discuss / 10630

Why is --pretty=format: so slow?

Subject: Why is --pretty=format: so slow?

## tl;dr

5 messages between Nov 4, 2007 and Nov 4, 2007.

replies: 4people: 3as markdown or json

Paul Mackerras· Nov 4, 2007, 03:42 UTC · lore

For some reason, using --pretty=format:... with git log is much slower than other formats. For example, on the kernel tree (on my quad G5):

$ time git log --pretty=oneline >/dev/null

real 0m2.165s user 0m2.092s sys 0m0.070s

$ time git log --pretty=raw >/dev/null

real 0m2.426s user 0m2.358s sys 0m0.068s

$ time git log --pretty="format:%H" >/dev/null

real 0m7.843s user 0m6.282s sys 0m1.557s

$ time git log --pretty="format:%H {%P} %ct" >/dev/null

real 0m7.950s user 0m6.374s sys 0m1.573s

Strace seems to indicate that git log is doing at least one sequence of open, fstat64, fcntl64, getdents64 and close for each line of output in the --pretty=format: cases, but not in the other cases. This seems rather unnecessary - could it be fixed? I'd like to use the last format listed above with gitk, but not if it is going to make things 3 times slower.

Paul.

Junio C Hamano· Nov 4, 2007, 04:22 UTC · re: Paul Mackerras · lore

Re: Why is --pretty=format: so slow?

Paul Mackerras <paulus@samba.org> writes:

> Strace seems to indicate that git log is doing at least one sequence
> of open, fstat64, fcntl64, getdents64 and close for each line of
> output in the --pretty=format: cases, but not in the other cases.

I bet that is coming from doing find_unique_abbrev() to fill fields %h, %t and %p, even when the output format does not ask for any of them.

Dscho, can we stop calling find_unique_abbrev() unconditionally before being asked?

René Scharfe· Nov 4, 2007, 10:31 UTC · re: Junio C Hamano · lore

Re: Why is --pretty=format: so slow?

Junio C Hamano schrieb:

Show 12 quoted lines

> Paul Mackerras <paulus@samba.org> writes:
> 
>> Strace seems to indicate that git log is doing at least one sequence
>> of open, fstat64, fcntl64, getdents64 and close for each line of
>> output in the --pretty=format: cases, but not in the other cases.
> 
> I bet that is coming from doing find_unique_abbrev() to fill
> fields %h, %t and %p, even when the output format does not ask
> for any of them.
> 
> Dscho, can we stop calling find_unique_abbrev() unconditionally
> before being asked?

Incidentally, I'm finishing a patch series to add git-describe style placeholders. It needs such an optimization even more badly (and has it). Speeding up other slow placeholder expansions falls out quite naturally. Please wait just a few minutes..

René

Junio C Hamano· Nov 4, 2007, 11:48 UTC · re: René Scharfe · lore

Re: Why is --pretty=format: so slow?

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Incidentally, I'm finishing a patch series to add git-describe style
> placeholders.  It needs such an optimization even more badly (and has
> it).  Speeding up other slow placeholder expansions falls out quite
> naturally.  Please wait just a few minutes..

Thanks, and take your time, as I am just going to bed, dreaming for a perfect series from one of the few people on this list whose patches I do not have to read to reject crap, but I do read to get impressed and admire ;-)

René Scharfe· Nov 4, 2007, 13:53 UTC · re: Junio C Hamano · lore

Re: Why is --pretty=format: so slow?

Junio C Hamano schrieb:

Show 11 quoted lines

> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> 
>> Incidentally, I'm finishing a patch series to add git-describe
>> style placeholders.  It needs such an optimization even more badly
>> (and has it).  Speeding up other slow placeholder expansions falls
>> out quite naturally.  Please wait just a few minutes..
> 
> Thanks, and take your time, as I am just going to bed, dreaming for a
> perfect series from one of the few people on this list whose patches
> I do not have to read to reject crap, but I do read to get impressed
> and admire ;-)

*blushes*

Well, it's certainly not perfect -- I just noticed I've sent the patches to your old address. Would you like me to resend them?

And, of course, I found a conceptual bug (which is impossible to trigger with the current code, fortunately), while looking over the changes a last time. *sigh*. I'll send a fix right away.

René