Re: git blame vs git log --follow performance

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

 



On Mon, Jan 27, 2014 at 4:10 AM, Joe Perches <joe@xxxxxxxxxxx> wrote:
> For instance (using the Linus' linux kernel git):
>
> $ time git log --follow -- drivers/firmware/google/Kconfig > /dev/null
>
> real    0m42.329s
> user    0m40.984s
> sys     0m0.792s
>
> $ time git blame -- drivers/firmware/google/Kconfig > /dev/null
>
> real    0m0.963s
> user    0m0.860s
> sys     0m0.096s
>

It's not fair to compare blame and log. If you compare, compare it to
non follow version

$ time git log --follow -- drivers/firmware/google/Kconfig > /dev/null

real    0m35.552s
user    0m35.120s
sys     0m0.383s

$ time git log -- drivers/firmware/google/Kconfig > /dev/null

real    0m4.366s
user    0m4.215s
sys     0m0.144s

Although because we need to detect rename, we can't really filter to
one path. So the base line is more like

$ time git log > /dev/null

real    0m29.338s
user    0m28.485s
sys     0m0.813s

with rename detection taking some more time.

> Perhaps adding a whole-file rename option to the
> "git log" history simplification mechanism could
> help?
>
> Thoughts?

I tested a version with rename detection logic removed. It did not
change the timing significantly. To improve --follow I think we need
to do something about path filtering.
-- 
Duy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]