Why is --pretty=format: so slow?

Why is --pretty=format: so slow?

[Paul Mackerras]

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.

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

[Junio C Hamano]

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?

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

[René Scharfe]

Junio C Hamano schrieb:
> 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é

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

[Junio C Hamano]

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 ;-)

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

[René Scharfe]

Junio C Hamano schrieb:
> 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é