{"thread":{"id":"14043","subject":"name-rev --stdin is slow","startedAt":"2008-06-19T21:10:12Z","lastAt":"2008-06-19T23:00:31Z","messageCount":4,"participants":["Lea Wiemann","Daniel Barkalow"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"80371","messageId":"485ACB34.2020901@gmail.com","threadId":"14043","inReplyTo":null,"subject":"name-rev --stdin is slow","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-19T21:10:12Z","receivedAt":"2008-06-19T21:10:12Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"name-rev --stdin has some really high start-up time.  The example below \nis on my git.git branch.  Is this unavoidable to make name-rev fast for \nnaming high numbers of revisions -- i.e. is it about amortization? \nStill, 0.7 seconds seems pretty excessive, and on linux-2.6 it even \ntakes 6 seconds.\n\nAnyone care to look into it?\n\n$ time echo HEAD | git name-rev --stdin\nHEAD\n\nreal\t0m0.748s\nuser\t0m0.588s\nsys\t0m0.080s\n$ time git name-rev HEAD\nHEAD master\n\nreal\t0m0.041s\nuser\t0m0.016s\nsys\t0m0.028s\n"},{"id":"80386","messageId":"alpine.LNX.1.00.0806191755510.19665@iabervon.org","threadId":"14043","inReplyTo":"485ACB34.2020901@gmail.com","subject":"Re: name-rev --stdin is slow","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-19T22:03:59Z","receivedAt":"2008-06-19T22:03:59Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 19 Jun 2008, Lea Wiemann wrote:\n\n> name-rev --stdin has some really high start-up time.  The example below is on\n> my git.git branch.  Is this unavoidable to make name-rev fast for naming high\n> numbers of revisions -- i.e. is it about amortization? Still, 0.7 seconds\n> seems pretty excessive, and on linux-2.6 it even takes 6 seconds.\n> \n> Anyone care to look into it?\n\nActually, I think it's the reverse: without --stdin, name-rev can do a \nfirst pass that lets it eliminate a lot of data from consideration; with \n--stdin, it doesn't know if an item it hasn't seen is going to need some \ndata, and so it's conservative and doesn't eliminate anything, which means \nthat each request is slower, at least until it's cached everything that \nyou turn out to care about.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"80387","messageId":"485AD90E.6000309@gmail.com","threadId":"14043","inReplyTo":"alpine.LNX.1.00.0806191755510.19665@iabervon.org","subject":"Re: name-rev --stdin is slow","fromName":"Lea Wiemann","fromEmail":"lewiemann@gmail.com","sentAt":"2008-06-19T22:09:18Z","receivedAt":"2008-06-19T22:09:18Z","isPatch":false,"sender":{"key":"lewiemann@gmail.com","avatar":null},"body":"Daniel Barkalow wrote:\n> Actually, I think it's the reverse: without --stdin, name-rev can do a \n> first pass that lets it eliminate a lot of data from consideration; with \n> --stdin, it doesn't know if an item it hasn't seen is going to need some \n> data, and so it's conservative and doesn't eliminate anything,\n\nAre you sure that's the case?  time git-name-rev --stdin < /dev/null \ngives the same high startup time without looking up anything.\n\nAnyways, it would be great if someone could try to fix that, since a \n6-second startup time on a repository like linux-2.6 makes the --stdin \noption unusable for applications like gitweb (for which it would \nactually be quite useful to reduce the number of forks).\n\n-- Lea\n"},{"id":"80398","messageId":"alpine.LNX.1.00.0806191849540.19665@iabervon.org","threadId":"14043","inReplyTo":"485AD90E.6000309@gmail.com","subject":"Re: name-rev --stdin is slow","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-06-19T23:00:31Z","receivedAt":"2008-06-19T23:00:31Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 20 Jun 2008, Lea Wiemann wrote:\n\n> Daniel Barkalow wrote:\n> > Actually, I think it's the reverse: without --stdin, name-rev can do a first\n> > pass that lets it eliminate a lot of data from consideration; with --stdin,\n> > it doesn't know if an item it hasn't seen is going to need some data, and so\n> > it's conservative and doesn't eliminate anything,\n> \n> Are you sure that's the case?  time git-name-rev --stdin < /dev/null gives the\n> same high startup time without looking up anything.\n\nAh, okay. There's a startup pass that goes through all of the refs (tags \nin particular), and does stuff with them, but only if they aren't filtered \nout.\n\n> Anyways, it would be great if someone could try to fix that, since a 6-second\n> startup time on a repository like linux-2.6 makes the --stdin option unusable\n> for applications like gitweb (for which it would actually be quite useful to\n> reduce the number of forks).\n\nIt might be possible to collect all of the input, set up the filter, and \ndo the (now cheaper) initial pass, but I don't think that would offer any \nreal advantage over just collecting them in the caller and calling \nname-rev with a long command line.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}