On Fri, Apr 5, 2019 at 6:29 PM Matheus Tavares Bernardino <matheus.bernardino@xxxxxx> wrote: > > On Thu, Apr 4, 2019 at 4:56 AM Christian Couder > <christian.couder@xxxxxxxxx> wrote: > > > > Nice investigation. About git status I wonder though if they have > > tried the possible optimizations, like untracked cache or > > core.fsmonitor. > > I don't know if they did, but I suggested them to check > core.commitGraph, pack.useBitmaps and core.untrackedCache (which Duy > suggested me in another thread). Thanks! It would be nice to know if it has improved things for them. > > I can't really tell as I haven't studied this, but from the links in > > your email I think it kind of makes sense. > > > > Instead of doing assign_blame()'s main loop in parallel though, if my > > focus was only making git blame faster, I think I would first try to > > cache xdl_hash_record() results and then if possible to compute > > xdl_hash_record() in parallel as it seems to be a big bottleneck and a > > quite low hanging fruit. > > Hm, I see. But although it would take more effort to add threading at > assign_blame(), wouldn't it be better because more work could be done > in parallel? I think it could be implemented in the same fashion git > grep does. Yeah, I agree that it seems to be worth the effort. > > I don't think you need to study everything yet, and I think you > > already did a lot of studying, so I would suggest you first try to > > send soon a proposal with the information you have right now, and then > > depending on the feedback you get and the time left (likely not > > much!!!), you might study some parts of the code a bit more later. > > Thanks a lot, Christian. I'm writing my proposal and will try to send it today. Great!
