Re: faster egit history page and a pure java "gitk"

[Robin Rosenberg <robin.rosenberg@dewire.com>]

Den Monday 24 March 2008 09.27.26 skrev Shawn O. Pearce:
> OK, so I decided a few weeks back that the history page was not fast
> enough.  I think I've spent the past 3 weeks writing true revision
> machinary for jgit, and now connecting it up to a UI visualizer.
>
>   git://repo.or.cz/egit/spearce.git plotter
>
> The history page has been completely replaced.  I saw Roger has
> some patches against the current history page.  :-|
The page was very messy. It was my first attempt at anything ui in
Eclipse at all. Like a child drawing his first picture of a person :)

> There are huge benefits to this infrastructure:
>
>  * Fast as snot.  We are literally just 10-20 ms slower than C Git
>    on the same hardware, same repository, for the same tree.  That
>    is pretty damn good, given that we are in Java.

On what repo is that measured?

As for Java speed, it is some two to three times slower than C on array 
intensive stuff. On just about anything else the difference is less.

The "Micro-optimize pack index v2 findOffset routine" commit suprises me
a little. The rearranged ObjectId layout does not. Could we do even better
using two long's and one int?

>  * Faster than gitk.  Yes, really.  My plot algorithm is not nearly
>    as good as Paulus' work, but I think its better than what we
>    have right now.
gitk has to talk to externa processess and parse things so I'm not surprised
we'd come to it some day.

>  * Nearly instant results without path limiter(s).  If the graph
>    doesn't require parent rewrites we are able to show results
>    almost immediately, and fill in the rest incrementally from
>    the background job.
>
>  * Lower memory usage.  By massive amounts.  I can't even begin to
>    tell you how much different it is.  Histories that we could not
>    show before can now be shown in <20M.  Our memory usage is much
>    lower than that of gitk.
This probably is related to speed too because the gc got to do a lot
of work.

>  * Multiple path limiters.  You can select more than one resource
>    (or directory!) at once and get the combined history for
>    all of them at once.  This is basically the same path limiter
>    algorithm that C Git/gitk rely upon for the same sort of query.
>    It is still limited to a single-repository, but I think we could
>    easily extend it to allow multiple-repository unions.  :-)
You mean submodules, real and "virtual" ?

>  * Common AWT and SWT drawing.  Most of the UI visualization code
>    is implemented in shared code that has no AWT or SWT specifics
>    about it.  This makes the renderer completely portable.  I have
>    both an AWT and an SWT implementation running (compare from the
>    command line "jgit glog HEAD" to the history view in Eclipse).
Sweet. Needs some polishing though. At least under Linux and small screens
with lots of pixels.

>  * Faster "RevCommit" class.  This class mostly replaces the older
>    "Commit" class.  Accessing data out of a RevCommit can be much
>    quicker than out of a Commit, plus a RevCommit gets the encoding
>    of the author, committer and message correct more of the time.
>    The downside is you can only get a RevCommit from a RevWalk,
>    or one of its subclasses.

Very impressive work Mr Shawn. I'll walk through and publish.

-- robin