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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
