transport activity is not displayed in progress widget

[Jeff Fortin Tam]

To test:
bzr checkout --lightweight lp:bzr-gtk
cd bzr-gtk
bzr viz

And then try scrolling in this graph of the 600 revisions. It is insanely slow, and that's on a core2 quad processor! For what it's worth, using Giggle to scroll pitivi's history is blazing fast (but then, this is a different test case; their tree graphs don't show a bunch of parallel lines/curves).

[Martin Pool (mbp)]

For me the performance is quite good, on a ~2 year old desktop machine running Ubuntu Jaunty. What platform are you on, and what graphics hardware do you have? Are you running bzr and bzr-gtk from a branch or a package?

[Andrew Cowie (afcowie)]

I'm not observing slowness _scrolling_, but using the up/down arrows to _navigate_ between revisions is insanely slow (or, at least, laggy) — monster CPU hit each step.

[that's over and above the fact that `bzr viz` takes forever to load, but I assume that's a separate issue]

This is with bzr-gtk from trunk (since there's no release that works with 1.15).

AfC

[Martin Pool (mbp)]

2009/6/22 Andrew Cowie <email address hidden>:
> I'm not observing slowness _scrolling_, but using the up/down arrows to
> _navigate_ between revisions is insanely slow (or, at least, laggy) —
> monster CPU hit each step.
>
> [that's over and above the fact that `bzr viz`  takes forever to load,
> but I assume that's a separate issue]
>
> This is with bzr-gtk from trunk (since there's no release that works
> with 1.15).

I believe you, but just for the sake of narrowing it down, I'll report
that for me holding down the arrow scrolls through them roughly as
fast as the key repeats.

--
Martin <http://launchpad.net/~mbp/>

[Andrew Cowie (afcowie)]

Ok, so I figured my foible out:

I have diffs turned on. That's what makes it slow. Turn it off, it's snappy.

But as I said, that's not "scrolling", which is what Jean-François reported. So I think I'll bow out of this. So much for being helpful.

[why diffs cause such slowness? is another issue. I know better than to compare to `gitview` (especially in view of where that code came from originally!), but... um...]

AfC

[Martin Pool (mbp)]

2009/6/22 Andrew Cowie <email address hidden>:
> Ok, so I figured my foible out:
>
> I have diffs turned on. That's what makes it slow. Turn it off, it's
> snappy.

OK, that certainly slows it down for me too. Maybe it should draw the
diff only when idle

--
Martin <http://launchpad.net/~mbp/>

[Jeff Fortin Tam (kiddo)]

> What platform are you on, and what graphics
> hardware do you have? Are you running bzr and bzr-gtk from a branch or
> a package?

Ubuntu 9.04, bzr from the PPA (1.15 IIRC?), using bzr-gtk from the bzr-gtk
branch (checked-out as ~/.bazaar/plugins/gtk/), and the benchmark is to run
bzr viz on that tree itself. (Did you try my repro instructions?)

The GPU is an Intel GMA 3100, driver 2.7.99somethingsomething + kernel
2.6.30, from the xorg edgers ppa from a few weeks ago (no crashes or
anything).

[Jeff Fortin Tam (kiddo)]

Actually, I didn't do a "bzr branch lp:bzr-gtk", I did a "bzr checkout --lightweight lp:bzr-gtk", now that I think of it.

[Vincent Ladeuil (vila)]

Since you use a lightweight checkout, you instructed bzr to *not* copy the historical data locally but instead access it remotely each time it's needed.

So you and Martin have been comparing network access times vs local access times.

Basically, either you pay for the history disk space or you pay for the network times, your choice.

Things would have been clearer for you if bzr viz were displaying the network activity (which it will RSN :) by using bzr report progress API (which is currently updated).

[Jeff Fortin Tam (kiddo)]

Yeah, it just didn't strike me at that moment that I was using a lightweight
checkout, and just assumed that there was a performance problem :) I'm glad
to hear that some better visual feedback is planned for network-bound
operations, so I'm leaving this bug open for that.

I somehow still wonder why it "lags" or moves not smoothly. I mean, is it
because it's getting the commit revision numbers + summaries + generating
the graph, all at once? Or is the latency just caused by the graphs?
If that's the case,
- perhaps the graph could be made asynchroneous to the rest so that
scrolling can still occur, while a progressbar says something like
"generating graph";
- or maybe the graph could be disabled for network-bound operations?

Those are just random thoughts/guesses, I have no idea how the code actually
works :)

[Gary van der Merwe (garyvdm)]

On Mon, Jun 22, 2009 at 5:18 PM, Jean-François Fortin
Tam<email address hidden> wrote:
> I somehow still wonder why it "lags" or moves not smoothly. I mean, is it
> because it's getting the commit revision numbers + summaries + generating
> the graph, all at once? Or is the latency just caused by the graphs?
> If that's the case,
> - perhaps the graph could be made asynchroneous to the rest so that
> scrolling can still occur, while a progressbar says something like
> "generating graph";
> - or maybe the graph could be disabled for network-bound operations?

The all revision numbers + graph are load/generated on load, but the
revision properties (summary, author, date) are only loaded when they
appear on screen, and cached. Because they are cached, scrolling back
to an area that you have already been too should be quick.