log._graph_view_revisions optimization

[Parth Malwankar]

Hello,

In order to do some optimization of bzr-grep I noticed using
--lsprof that about 45% of the time is spend getting the
revision range tuple (revid, revno, merge_depth) for which
bzr-grep uses bzrlib.log._graph_view_revisions

Forcing it to a list (as its lazy):
    given_revs = logcmd._graph_view_revisions(...)
    given_revs = list(given_revs)

Using the emacs repo as test data I found that around
6.5s are spent on this on my machine (last:5..last:1). The total
grep time is ~15s with rev range.

I don't know much about _graph_view_revisions but,
interestingly, this time taken _seems_ to depend on the total
history size rather than the range window. Doing (last:5..last:1)
for a repo of ~100revs it takes only about 0.3s for hot cache.

I also noticed, _graph_view_revisions, _always_ returns the merged
revisions, e.g. 1.1.1, which I either user or reject depending on
the --levels setting by the user. Can this be controlled (based on
--levels) in case it gives a performance gain?

For a single revision case (-r spec) I have added the optimization
to bypass the _graph_view_revisions call. I am wondering if
there is something that can be done to get a revision range faster.

-- 
Regards,
Parth