Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-22 Thread Jeff King
On Thu, Nov 23, 2017 at 11:19:42AM +0900, Junio C Hamano wrote: > Jeff King writes: > > > And lazy-load wouldn't help you there for a normal: > > > > git log > > > > But what's interesting in your command is the pretty-format. Even though > > decoration is turned on, your

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-22 Thread Junio C Hamano
Jeff King writes: > And lazy-load wouldn't help you there for a normal: > > git log > > But what's interesting in your command is the pretty-format. Even though > decoration is turned on, your format doesn't show any. So we never > actually ask "is this commit decorated" and the

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-22 Thread Jeff King
On Wed, Nov 22, 2017 at 03:21:06PM -0800, Phil Hord wrote: > Hm. I think I was confused. > > I wrote v1 of this patch a few months ago. Clearly I was wrong about > rev-parse being afflicted. We have a script that was suffering and it > uses both "git log --format=%h" and "git rev-parse" to get

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-22 Thread Phil Hord
On Wed, Nov 22, 2017 at 1:27 PM, Jeff King wrote: > On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote: > >> With many thousands of references, a simple `git rev-parse HEAD` may take >> more than a second to return because it first loads all the refs into >> memory even

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-22 Thread Jeff King
On Tue, Nov 21, 2017 at 03:43:36PM -0800, Phil Hord wrote: > With many thousands of references, a simple `git rev-parse HEAD` may take > more than a second to return because it first loads all the refs into > memory even though it will never use them. The overall goal of lazy-loading seems

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-22 Thread Phil Hord
On Tue, Nov 21, 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > I am not sure if "maybe_" is a good name here, though. If anything, > you are making the semantics of "load_ref_decorations()" to "maybe" > (but I do not suggest renaming that one). >

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-21 Thread Junio C Hamano
Junio C Hamano writes: > Other than that, I like what this patch attempts to do. A nicely > identified low-hanging fruit ;-). Having said that, this will have a bad interaction with another topic in flight: <20171121213341.13939-1-rafa.al...@gmail.com> Perhaps this should

Re: [PATCH] defer expensive load_ref_decorations until needed

2017-11-21 Thread Junio C Hamano
Phil Hord writes: > With many thousands of references, a simple `git rev-parse HEAD` may take > more than a second to return because it first loads all the refs into > memory even though it will never use them. > > Defer loading any references until we actually need them. >

[PATCH] defer expensive load_ref_decorations until needed

2017-11-21 Thread Phil Hord
With many thousands of references, a simple `git rev-parse HEAD` may take more than a second to return because it first loads all the refs into memory even though it will never use them. Defer loading any references until we actually need them. Signed-off-by: Phil Hord ---