Duy Nguyen <pclouds@xxxxxxxxx> writes: > On Tue, Apr 2, 2019 at 5:30 PM David Kastrup <dak@xxxxxxx> wrote: >> >> 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). > > 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) I don't expect it to go anywhere but will do. Feel free to herd it. -- David Kastrup
