* name-rev --stdin is slow
@ 2008-06-19 21:10 Lea Wiemann
2008-06-19 22:03 ` Daniel Barkalow
0 siblings, 1 reply; 4+ messages in thread
From: Lea Wiemann @ 2008-06-19 21:10 UTC (permalink / raw)
To: Git Mailing List
name-rev --stdin has some really high start-up time. The example below
is on my git.git branch. Is this unavoidable to make name-rev fast for
naming high numbers of revisions -- i.e. is it about amortization?
Still, 0.7 seconds seems pretty excessive, and on linux-2.6 it even
takes 6 seconds.
Anyone care to look into it?
$ time echo HEAD | git name-rev --stdin
HEAD
real 0m0.748s
user 0m0.588s
sys 0m0.080s
$ time git name-rev HEAD
HEAD master
real 0m0.041s
user 0m0.016s
sys 0m0.028s
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: name-rev --stdin is slow
2008-06-19 21:10 name-rev --stdin is slow Lea Wiemann
@ 2008-06-19 22:03 ` Daniel Barkalow
2008-06-19 22:09 ` Lea Wiemann
0 siblings, 1 reply; 4+ messages in thread
From: Daniel Barkalow @ 2008-06-19 22:03 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Git Mailing List
On Thu, 19 Jun 2008, Lea Wiemann wrote:
> name-rev --stdin has some really high start-up time. The example below is on
> my git.git branch. Is this unavoidable to make name-rev fast for naming high
> numbers of revisions -- i.e. is it about amortization? Still, 0.7 seconds
> seems pretty excessive, and on linux-2.6 it even takes 6 seconds.
>
> Anyone care to look into it?
Actually, I think it's the reverse: without --stdin, name-rev can do a
first pass that lets it eliminate a lot of data from consideration; with
--stdin, it doesn't know if an item it hasn't seen is going to need some
data, and so it's conservative and doesn't eliminate anything, which means
that each request is slower, at least until it's cached everything that
you turn out to care about.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: name-rev --stdin is slow
2008-06-19 22:03 ` Daniel Barkalow
@ 2008-06-19 22:09 ` Lea Wiemann
2008-06-19 23:00 ` Daniel Barkalow
0 siblings, 1 reply; 4+ messages in thread
From: Lea Wiemann @ 2008-06-19 22:09 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Git Mailing List
Daniel Barkalow wrote:
> Actually, I think it's the reverse: without --stdin, name-rev can do a
> first pass that lets it eliminate a lot of data from consideration; with
> --stdin, it doesn't know if an item it hasn't seen is going to need some
> data, and so it's conservative and doesn't eliminate anything,
Are you sure that's the case? time git-name-rev --stdin < /dev/null
gives the same high startup time without looking up anything.
Anyways, it would be great if someone could try to fix that, since a
6-second startup time on a repository like linux-2.6 makes the --stdin
option unusable for applications like gitweb (for which it would
actually be quite useful to reduce the number of forks).
-- Lea
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: name-rev --stdin is slow
2008-06-19 22:09 ` Lea Wiemann
@ 2008-06-19 23:00 ` Daniel Barkalow
0 siblings, 0 replies; 4+ messages in thread
From: Daniel Barkalow @ 2008-06-19 23:00 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Git Mailing List
On Fri, 20 Jun 2008, Lea Wiemann wrote:
> Daniel Barkalow wrote:
> > Actually, I think it's the reverse: without --stdin, name-rev can do a first
> > pass that lets it eliminate a lot of data from consideration; with --stdin,
> > it doesn't know if an item it hasn't seen is going to need some data, and so
> > it's conservative and doesn't eliminate anything,
>
> Are you sure that's the case? time git-name-rev --stdin < /dev/null gives the
> same high startup time without looking up anything.
Ah, okay. There's a startup pass that goes through all of the refs (tags
in particular), and does stuff with them, but only if they aren't filtered
out.
> Anyways, it would be great if someone could try to fix that, since a 6-second
> startup time on a repository like linux-2.6 makes the --stdin option unusable
> for applications like gitweb (for which it would actually be quite useful to
> reduce the number of forks).
It might be possible to collect all of the input, set up the filter, and
do the (now cheaper) initial pass, but I don't think that would offer any
real advantage over just collecting them in the caller and calling
name-rev with a long command line.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2008-06-19 23:01 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-19 21:10 name-rev --stdin is slow Lea Wiemann
2008-06-19 22:03 ` Daniel Barkalow
2008-06-19 22:09 ` Lea Wiemann
2008-06-19 23:00 ` Daniel Barkalow
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox