On Tue, Apr 2, 2019 at 5:30 PM David Kastrup <d...@gnu.org> wrote: > > Duy Nguyen <pclo...@gmail.com> writes: > > > On Tue, Apr 2, 2019 at 7:52 AM Matheus Tavares > > <matheus.bernard...@usp.br> 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).
I didn't really read the patch (I don't know much about blame.c to really contribute anything there). But a quick "git blame --show-stats unpack-trees.c" shows this Without the patch: num read blob: 767 num get patch: 425 num commits: 343 With the patch: num read blob: 419 num get patch: 425 num commits: 343 That's a nice reduction of blob reading. On a typical small file, the actual time saving might be not much. But it could really help when you blame a large file. Perhaps you could resubmit it again for inclusion? (at least a sign-off-by is missing then) > Rebased/appended. > > -- > David Kastrup -- Duy
