Re: faster egit history page and a pure java "gitk"
- From
Robin Rosenberg <robin.rosenberg@dewire.com>
- Date
- Mar 24, 2008, 14:06 UTC
- Message-ID
- <200803241406.54759.robin.rosenberg@dewire.com>
- In-Reply-To
- <20080324092726.GQ8410@spearce.org>
Den Monday 24 March 2008 09.27.26 skrev Shawn O. Pearce:
Show 8 quoted lines
> 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 :)
Show 5 quoted lines
> 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.
Show 9 quoted lines
> * 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.
Show 6 quoted lines
> * 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" ?
Show 5 quoted lines
> * 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.
Show 6 quoted lines
> * 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