{"thread":{"id":"12837","subject":"faster egit history page and a pure java \"gitk\"","startedAt":"2008-03-24T09:27:26Z","lastAt":"2008-03-26T04:52:44Z","messageCount":16,"participants":["Shawn O. Pearce","Roger C. Soares","Robin Rosenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"72867","messageId":"20080324092726.GQ8410@spearce.org","threadId":"12837","inReplyTo":null,"subject":"faster egit history page and a pure java \"gitk\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-24T09:27:26Z","receivedAt":"2008-03-24T09:27:26Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"OK, so I decided a few weeks back that the history page was not fast\nenough. I think I've spent the past 3 weeks writing true revision\nmachinary for jgit, and now connecting it up to a UI visualizer.\n\n git://repo.or.cz/egit/spearce.git plotter\n\nThe history page has been completely replaced. I saw Roger has\nsome patches against the current history page. :-|\n\nThere are huge benefits to this infrastructure:\n\n * Fast as snot. We are literally just 10-20 ms slower than C Git\n on the same hardware, same repository, for the same tree. That\n is pretty damn good, given that we are in Java.\n\n * Faster than gitk. Yes, really. My plot algorithm is not nearly\n as good as Paulus' work, but I think its better than what we\n have right now.\n\n * Nearly instant results without path limiter(s). If the graph\n doesn't require parent rewrites we are able to show results\n almost immediately, and fill in the rest incrementally from\n the background job.\n\n * Lower memory usage. By massive amounts. I can't even begin to\n tell you how much different it is. Histories that we could not\n show before can now be shown in <20M. Our memory usage is much\n lower than that of gitk.\n\n * Multiple path limiters. You can select more than one resource\n (or directory!) at once and get the combined history for\n all of them at once. This is basically the same path limiter\n algorithm that C Git/gitk rely upon for the same sort of query.\n It is still limited to a single-repository, but I think we could\n easily extend it to allow multiple-repository unions. :-)\n\n * Parent/child hyperlinks in message viewer. Like gitk you can\n now click on the parent and child commit SHA-1s to jump up and\n down the graph.\n\n * Grep options available. Not implemented in the UI yet, but\n the lower level machinary supports author/committer/log message\n grep functions.\n\n * Interesting/not-interesting flags available. Not implemented\n in the UI yet, but the lower level machinary can do things like\n \"^foo bar\" to show all commits in bar that are not in foo.\n\n * More modular code. Its broken apart much better. We don't have\n 3000 lines in a single class.\n\n * Common AWT and SWT drawing. Most of the UI visualization code\n is implemented in shared code that has no AWT or SWT specifics\n about it. This makes the renderer completely portable. I have\n both an AWT and an SWT implementation running (compare from the\n command line \"jgit glog HEAD\" to the history view in Eclipse).\n\n * Faster \"RevCommit\" class. This class mostly replaces the older\n \"Commit\" class. Accessing data out of a RevCommit can be much\n quicker than out of a Commit, plus a RevCommit gets the encoding\n of the author, committer and message correct more of the time.\n The downside is you can only get a RevCommit from a RevWalk,\n or one of its subclasses.\n\n-- \nShawn.\n"},{"id":"72886","messageId":"47E7ADA3.2060906@intelinet.com.br","threadId":"12837","inReplyTo":"20080324092726.GQ8410@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Roger C. Soares","fromEmail":"rogersoares@intelinet.com.br","sentAt":"2008-03-24T13:33:23Z","receivedAt":"2008-03-24T13:33:23Z","isPatch":false,"sender":{"key":"rogersoares@intelinet.com.br","avatar":null},"body":"\nShawn O. Pearce escreveu:\n> OK, so I decided a few weeks back that the history page was not fast\n> enough. I think I've spent the past 3 weeks writing true revision\n> machinary for jgit, and now connecting it up to a UI visualizer.\n>\n> git://repo.or.cz/egit/spearce.git plotter\n>\n> The history page has been completely replaced. I saw Roger has\n> some patches against the current history page. :-|\n> \nHi Shawn. This is awesome, I can't wait to see this integrated in the \nmain repo :)\n\nI don't spend much time working on egit so I usually take a while to \nmake small things, but I can certainly merge my patches on top of yours.\n\nRobin, how should I proceed, resend all my patches from the weekend on \ntop of Shawn's tree?\n\n[]s,\nRoger.\n"},{"id":"72891","messageId":"200803241406.54759.robin.rosenberg@dewire.com","threadId":"12837","inReplyTo":"20080324092726.GQ8410@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2008-03-24T14:06:54Z","receivedAt":"2008-03-24T14:06:54Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Den Monday 24 March 2008 09.27.26 skrev Shawn O. Pearce:\n> OK, so I decided a few weeks back that the history page was not fast\n> enough. I think I've spent the past 3 weeks writing true revision\n> machinary for jgit, and now connecting it up to a UI visualizer.\n>\n> git://repo.or.cz/egit/spearce.git plotter\n>\n> The history page has been completely replaced. I saw Roger has\n> some patches against the current history page. :-|\nThe page was very messy. It was my first attempt at anything ui in\nEclipse at all. Like a child drawing his first picture of a person :)\n\n> There are huge benefits to this infrastructure:\n>\n> * Fast as snot. We are literally just 10-20 ms slower than C Git\n> on the same hardware, same repository, for the same tree. That\n> is pretty damn good, given that we are in Java.\n\nOn what repo is that measured?\n\nAs for Java speed, it is some two to three times slower than C on array \nintensive stuff. On just about anything else the difference is less.\n\nThe \"Micro-optimize pack index v2 findOffset routine\" commit suprises me\na little. The rearranged ObjectId layout does not. Could we do even better\nusing two long's and one int?\n\n> * Faster than gitk. Yes, really. My plot algorithm is not nearly\n> as good as Paulus' work, but I think its better than what we\n> have right now.\ngitk has to talk to externa processess and parse things so I'm not surprised\nwe'd come to it some day.\n\n> * Nearly instant results without path limiter(s). If the graph\n> doesn't require parent rewrites we are able to show results\n> almost immediately, and fill in the rest incrementally from\n> the background job.\n>\n> * Lower memory usage. By massive amounts. I can't even begin to\n> tell you how much different it is. Histories that we could not\n> show before can now be shown in <20M. Our memory usage is much\n> lower than that of gitk.\nThis probably is related to speed too because the gc got to do a lot\nof work.\n\n> * Multiple path limiters. You can select more than one resource\n> (or directory!) at once and get the combined history for\n> all of them at once. This is basically the same path limiter\n> algorithm that C Git/gitk rely upon for the same sort of query.\n> It is still limited to a single-repository, but I think we could\n> easily extend it to allow multiple-repository unions. :-)\nYou mean submodules, real and \"virtual\" ?\n\n> * Common AWT and SWT drawing. Most of the UI visualization code\n> is implemented in shared code that has no AWT or SWT specifics\n> about it. This makes the renderer completely portable. I have\n> both an AWT and an SWT implementation running (compare from the\n> command line \"jgit glog HEAD\" to the history view in Eclipse).\nSweet. Needs some polishing though. At least under Linux and small screens\nwith lots of pixels.\n\n> * Faster \"RevCommit\" class. This class mostly replaces the older\n> \"Commit\" class. Accessing data out of a RevCommit can be much\n> quicker than out of a Commit, plus a RevCommit gets the encoding\n> of the author, committer and message correct more of the time.\n> The downside is you can only get a RevCommit from a RevWalk,\n> or one of its subclasses.\n\nVery impressive work Mr Shawn. I'll walk through and publish.\n\n-- robin\n"},{"id":"72893","messageId":"200803241410.52566.robin.rosenberg@dewire.com","threadId":"12837","inReplyTo":"47E7ADA3.2060906@intelinet.com.br","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2008-03-24T14:10:52Z","receivedAt":"2008-03-24T14:10:52Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Den Monday 24 March 2008 13.33.23 skrev Roger C. Soares:\n> Robin, how should I proceed, resend all my patches from the weekend on\n> top of Shawn's tree?\n\nPlease, do.\n\n-- robin\n"},{"id":"72894","messageId":"200803241431.08633.robin.rosenberg@dewire.com","threadId":"12837","inReplyTo":"20080324092726.GQ8410@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\" so","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2008-03-24T14:31:08Z","receivedAt":"2008-03-24T14:31:08Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Måndagen 24 March 2008 09.27.26 skrev Shawn O. Pearce:\n> OK, so I decided a few weeks back that the history page was not fast\n> enough. I think I've spent the past 3 weeks writing true revision\n> machinary for jgit, and now connecting it up to a UI visualizer.\n>\n> git://repo.or.cz/egit/spearce.git plotter\n>\n> The history page has been completely replaced. I saw Roger has\n> some patches against the current history page. :-|\n\nDid you lose compare?\n\nOk, found it, but it only shows one file in the compare editor, so I cannot \nwalk through all changes in the commit with Ctrl-. and Ctrl-,\n\n-- robin\n"},{"id":"72997","messageId":"20080325044308.GA4759@spearce.org","threadId":"12837","inReplyTo":"47E7ADA3.2060906@intelinet.com.br","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-25T04:43:08Z","receivedAt":"2008-03-25T04:43:08Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Roger C. Soares\" wrote:\n> Shawn O. Pearce escreveu:\n> >OK, so I decided a few weeks back that the history page was not fast\n> >enough. I think I've spent the past 3 weeks writing true revision\n> >machinary for jgit, and now connecting it up to a UI visualizer.\n> >\n> > git://repo.or.cz/egit/spearce.git plotter\n> >\n> >The history page has been completely replaced. I saw Roger has\n> >some patches against the current history page. :-|\n> \n> Hi Shawn. This is awesome, I can't wait to see this integrated in the \n> main repo :)\n> \n> I don't spend much time working on egit so I usually take a while to \n> make small things, but I can certainly merge my patches on top of yours.\n> \n> Robin, how should I proceed, resend all my patches from the weekend on \n> top of Shawn's tree?\n\nI just pushed a newer version out that contains support for showing\ncommits using a bold font if the commit has the highlightFlag set\non it. I assume you were trying to work on a feature like gitk\nhas where you can type in a string and have gitk bold all of the\ncommits that contain that string in the message, right?\n\nIf you look at the newer internal.history.GitHistoryPage class there\nis a historyFlag available as an instance member. We also have an\nSWTCommitList allocated in the inputSet() method. The SWTCommitList\nhas an applyFlag method that accepts a RevFilter and adds the passed\nRevFlag onto any commit that matches the filter.\n\nThere are a lot of RevFilter implementations, take a look at the\nrevwalk.filter package, or see the command line parsing code in\nRevWalkTextBuiltin. We have ones for author, committer, message...\n\nSo a good part of the code is there to do a bold/unbold thing.\nThere's also indexOf and lastIndexOf methods on SWTCommitList that\ncan search for the highlightFlag in either direction from a given\nrow index, making a prev/next feature pretty easy.\n\nI decided to leave some low hanging fruit. There's bigger and\nmore complex issues still lurking in the revwalk/treewalk features.\n\n-- \nShawn.\n"},{"id":"72998","messageId":"20080325044832.GB4759@spearce.org","threadId":"12837","inReplyTo":"200803241431.08633.robin.rosenberg@dewire.com","subject":"Re: faster egit history page and a pure java \"gitk\" so","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-25T04:48:32Z","receivedAt":"2008-03-25T04:48:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> Måndagen 24 March 2008 09.27.26 skrev Shawn O. Pearce:\n> > OK, so I decided a few weeks back that the history page was not fast\n> > enough. I think I've spent the past 3 weeks writing true revision\n> > machinary for jgit, and now connecting it up to a UI visualizer.\n> >\n> > git://repo.or.cz/egit/spearce.git plotter\n> >\n> > The history page has been completely replaced. I saw Roger has\n> > some patches against the current history page. :-|\n> \n> Did you lose compare?\n> \n> Ok, found it, but it only shows one file in the compare editor, so I cannot \n> walk through all changes in the commit with Ctrl-. and Ctrl-,\n\nYea. The compare linkage in the prior history view was a little\nunclear and I was trying to put something together. So I went\nwith a really quick and dirty linkage that worked for the simple\nsingle file case. Ideally it should get fully ported over, but\nthe underlying concepts like GitFileRevision are probably going\nto go by the wayside with RevWalk and TreeWalk being available.\nSo its probably trivial to port.\n\n-- \nShawn.\n"},{"id":"73000","messageId":"47E8889E.6090403@intelinet.com.br","threadId":"12837","inReplyTo":"20080324092726.GQ8410@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Roger C. Soares","fromEmail":"rogersoares@intelinet.com.br","sentAt":"2008-03-25T05:07:42Z","receivedAt":"2008-03-25T05:07:42Z","isPatch":false,"sender":{"key":"rogersoares@intelinet.com.br","avatar":null},"body":"Shawn O. Pearce escreveu:\n> OK, so I decided a few weeks back that the history page was not fast\n> enough. I think I've spent the past 3 weeks writing true revision\n> machinary for jgit, and now connecting it up to a UI visualizer.\n>\n> git://repo.or.cz/egit/spearce.git plotter\n>\n> The history page has been completely replaced. I saw Roger has\n> some patches against the current history page. :-|\n> \nHi Guys,\n\nI saw it running now, here are my initial comments/impressions:\n\nI have a git.git clone on my eclipse and now egit can open it, cool! :) \nBut it wasn't that fast, it took some minutes to finish building the \nwhole tree. Also, changing projects (different git repos) makes the cpu \ngo very high, and what opened fast the first time takes minutes after...\n\nWhen reading the email I thought the new history page would have the \nsame features from the current, but it doesn't. It looks promissing thought.\n\nMy first impression is that I like the current way of showing files in \nthe strutucture compare better. In the future I would like the option to \nmake it open on the left pane (where package explorer is) and have the \noptions to collapse/expand directories, present in flat/hierarchical \nmodes, have the fast view, etc.\n\nComments now can't be automatically wrapped. I actually prefer to leave \nwrapping to the computer, I don't like having to manually fix line \nlenghts when amending a comment, I think eclipse should do it. Also, \ncurrently, the history page usually has little space allocated for it \nand currently the first lines of the comment are visible. In the new \npage I have to scroll to see the comment when the history page is not \nmaximized.\n\n[]s,\nRoger.\n"},{"id":"72999","messageId":"20080325051040.GC4759@spearce.org","threadId":"12837","inReplyTo":"200803241406.54759.robin.rosenberg@dewire.com","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-25T05:10:40Z","receivedAt":"2008-03-25T05:10:40Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Robin Rosenberg wrote:\n> Den Monday 24 March 2008 09.27.26 skrev Shawn O. Pearce:\n> > git://repo.or.cz/egit/spearce.git plotter\n> >\n> > The history page has been completely replaced.\n>\n> The page was very messy. It was my first attempt at anything ui in\n> Eclipse at all. Like a child drawing his first picture of a person :)\n\nIt was pretty good. I actually learned from your work before\nreplacing it. My motivation wasn't about the look, but about\nthe speed of it. :)\n \n> > There are huge benefits to this infrastructure:\n> >\n> > * Fast as snot. We are literally just 10-20 ms slower than C Git\n> > on the same hardware, same repository, for the same tree. That\n> > is pretty damn good, given that we are in Java.\n> \n> On what repo is that measured?\n\ngit.git, starting from 0e545f75169e2c260dfb4445203c23cafdfc76ef, which\nis dated Dec 22 2007, so its a bit dated, but not too far back to be\ncompletely useless.\n\ngit.git is a toy compared to other projects, yes, but its what I\nhad on hand in my egit work area. I haven't tried larger projects\n(like say linux-2.6 or OOo).\n\n> As for Java speed, it is some two to three times slower than C on array \n> intensive stuff. On just about anything else the difference is less.\n\nDuring this work I've found that even with Java 6's HotSpot the way\nyou write the code in Java affects how the JIT optimizes it. In some\ncases hand-unrolling loops (like say a 20 byte SHA-1 compare routine)\nmakes a big impact. Using \"p + 1\", \"p + 2\", \"p + 3\" to access into the\narray can be faster than \"p++\", \"p++', \"p++\".\n \n> The \"Micro-optimize pack index v2 findOffset routine\" commit suprises me\n> a little.\n\nMe too. I assumed the compiler+JIT would be able to figure out that\n\"a * 5\" can be rewritten as \"a << 2 + a\", but alas they didn't. The\nrewriting I did there was part of the boost I got.\n\n> The rearranged ObjectId layout does not. Could we do even better\n> using two long's and one int?\n\nI actually started with the two long and one int layout but it was\nquite a bit slower than the five int case. Keep in mind this was\non a 32 bit Windows system; on an x86-64 or SPARC the two longs may\nbe faster due to the 64 bit registers being available to the JIT.\n \n> > * Lower memory usage. By massive amounts. I can't even begin to\n> > tell you how much different it is. Histories that we could not\n> > show before can now be shown in <20M. Our memory usage is much\n> > lower than that of gitk.\n>\n> This probably is related to speed too because the gc got to do a lot\n> of work.\n\nYup. The massive memory usage of the prior history view is actually\nwhat drove me to do this work. I was watching the memory meter on\nthe workbench while trying to open the history of my git.git clone\n(HEAD is just pegged on the commit above) and realized something was\nreally wrong if we were spiking up through 150M and onward just to\npull up the history. It also took several minutes. :-|\n \n> > * Multiple path limiters. You can select more than one resource\n> > (or directory!) at once and get the combined history for\n> > all of them at once. This is basically the same path limiter\n> > algorithm that C Git/gitk rely upon for the same sort of query.\n> > It is still limited to a single-repository, but I think we could\n> > easily extend it to allow multiple-repository unions. :-)\n>\n> You mean submodules, real and \"virtual\" ?\n\nYes. Or if projects are in different repositories and the user\nselects files in both and asks for history we could (in theory) show\na combined graph showing the commits from both repositories. If they\nhave no sort of connected history you'll still get interleaved\ntimestamps, but there will be at least two lanes running down the\nentire graph.\n\nMost of the abstractions are there. It shouldn't be difficult to\nchange RevWalk and TreeWalk to take some sort of new interface\ninstead of the Repository, where that interface can delegate\nto either one Repository, or search through a set of packfiles\nfrom multiple repositories, and then search through their loose\nobjects. That's really all that should be needed to union together\nrepositories.\n \n> > * Common AWT and SWT drawing. Most of the UI visualization code\n> > is implemented in shared code that has no AWT or SWT specifics\n> > about it. This makes the renderer completely portable. I have\n> > both an AWT and an SWT implementation running (compare from the\n> > command line \"jgit glog HEAD\" to the history view in Eclipse).\n>\n> Sweet. Needs some polishing though. At least under Linux and small screens\n> with lots of pixels.\n\nYea, I agree. I tried drawing it with 3 pixel wide rectangles\ntoday but it looked like c**p^H^H^H^Hnot the best thing I have\never written. But it is more readable, so we'll have to come back\nto that and see if we can't do better.\n \n-- \nShawn.\n"},{"id":"73001","messageId":"20080325053649.GE4759@spearce.org","threadId":"12837","inReplyTo":"47E8889E.6090403@intelinet.com.br","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-25T05:36:49Z","receivedAt":"2008-03-25T05:36:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Roger C. Soares\" wrote:\n> Shawn O. Pearce escreveu:\n> >The history page has been completely replaced.\n> \n> I have a git.git clone on my eclipse and now egit can open it, cool! :) \n\nYea, that was my impression too. \"Yay, it can open git.git!\" :)\n\n> But it wasn't that fast, it took some minutes to finish building the \n> whole tree. Also, changing projects (different git repos) makes the cpu \n> go very high, and what opened fast the first time takes minutes after...\n\nHmm. How long does C Git take for \"git rev-list HEAD >/dev/null\" ?\nI have thus far only tuned the lower level machinary, and there\nmay still be tuning left there, but I _really_ have not tried to\ntune the plotting portion yet.\n\nI did push something out a few minutes ago (b66eae Limit the number\nof UI refreshes ...) that may help improve performance on larger\nhistories.\n\nAnother thing is how many pack files/loose objects do you have?\nThe loose objects are harder to access, and jgit is currently\nlacking some of the pack search tricks that C Git uses to get\ngood performance. As such all of my testing has been working on\na fully packed repository that has exactly one packfile in it,\nwith no alternates.\n\nIts _almost_ acceptable to me. We can still do better, but there's\na point at which we just can't get past. We probably can't beat\nrev-list, but I think we should be able to beat gitk almost always.\nIn the simple fully packed case \"jgit glog\" beats gitk at opening\nthe full graph and displaying it.\n\n> When reading the email I thought the new history page would have the \n> same features from the current, but it doesn't. It looks promissing thought.\n\nNope. Sorry. Its basically a rewrite.\n \n> My first impression is that I like the current way of showing files in \n> the strutucture compare better.\n\nI actually prefer the individual files in the right pane, like gitk\ndoes, as I like to browse up and down sometimes looking at changes.\nMaybe we can make it an option to show that right side panel,\nand give a button (or IOpenListener on the graph table?) to let\nyou open the whole commit in the structure compare view.\n\n> In the future I would like the option to \n> make it open on the left pane (where package explorer is) and have the \n> options to collapse/expand directories, present in flat/hierarchical \n> modes, have the fast view, etc.\n\nOooh. Sounds fun.\n \n> Comments now can't be automatically wrapped.\n\nOversight/planned loss of feature. I'm a strong believer of showing\nthe commit message *exactly* as recorded, which means don't do\nline wrapping of it. Things like character encoding translation\nand indenting the left side 2-4 spaces to keep it unambiguous from\nheaders is fine when showing it to a human, but otherwise it should\nmatch what the user wrote.\n\nI forgot to offer a wrap option. If we do enable line wrapping I\nthink we should give the user a way to toggle it on/off for the\nmessage area viewer so that if line wrapping is enabled and its\nborking the current message (e.g. a nice pretty ASCII diagram)\nyou can disable it.\n\n> I actually prefer to leave \n> wrapping to the computer, I don't like having to manually fix line \n> lenghts when amending a comment, I think eclipse should do it. Also, \n> currently, the history page usually has little space allocated for it \n> and currently the first lines of the comment are visible. In the new \n> page I have to scroll to see the comment when the history page is not \n> maximized.\n\nYea, I started to notice that myself today. The area isn't quite\nwide enough, and I was using Eclipse on a very high resolution CRT\nand it was taking up a good 80% of the display. Most users can't\nsanely devote the area I did to the History view, and it was still\nnot wide enough for some git.git messages.\n\nThanks for the feedback. Obviously its still got a lot of areas\nfor improvements.\n\n-- \nShawn.\n"},{"id":"73013","messageId":"20080325080959.GG4759@spearce.org","threadId":"12837","inReplyTo":"20080325053649.GE4759@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-25T08:09:59Z","receivedAt":"2008-03-25T08:09:59Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> \"Roger C. Soares\" wrote:\n> \n> > But it wasn't that fast, it took some minutes to finish building the \n> > whole tree. Also, changing projects (different git repos) makes the cpu \n> > go very high, and what opened fast the first time takes minutes after...\n\nSomething else I noticed - the core.packedGit* settings make a\ndifference on performance. On Windows XP with Java 6 I am getting\nmuch better performance (200 ms lower running time) by using a much\nsmaller window size and disabling mmap:\n\n\t[core]\n\t\tpackedGitWindowSize = 8k\n\t\tpackedGitLimit = 10m\n\t\tpackedGitMMAP = false\n\nby default jgit is using mmap, as Robin has reported it runs faster\nthat way for him. But I have never been able to reproduce that on\nMac OS 10.4/Java 5 or Windows XP/Java 6. In both systems setting\nmmap to false has performed better, even on the initial first set\nof hits to the cache where we have to read in the blocks vs. mmap\nthem. The ByteBuffer API is just that much slower than accessing\na byte[] directly when shoving it through inflate. We spend at\nleast 30% of our time in inflate.\n\n-- \nShawn.\n"},{"id":"73038","messageId":"47E8F128.1080609@intelinet.com.br","threadId":"12837","inReplyTo":"20080325044308.GA4759@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Roger C. Soares","fromEmail":"rogersoares@intelinet.com.br","sentAt":"2008-03-25T12:33:44Z","receivedAt":"2008-03-25T12:33:44Z","isPatch":false,"sender":{"key":"rogersoares@intelinet.com.br","avatar":null},"body":"Shawn O. Pearce escreveu:\n> I just pushed a newer version out that contains support for showing\n> commits using a bold font if the commit has the highlightFlag set\n> on it. I assume you were trying to work on a feature like gitk\n> has where you can type in a string and have gitk bold all of the\n> commits that contain that string in the message, right?\n> \nYep, the find toolbar highlights the commits in bold. It's probably the \nfirst thing that I'll try to port. Thanks for the info.\n\n[]s,\nRoger.\n"},{"id":"73040","messageId":"47E90246.3030509@intelinet.com.br","threadId":"12837","inReplyTo":"20080325053649.GE4759@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Roger C. Soares","fromEmail":"rogersoares@intelinet.com.br","sentAt":"2008-03-25T13:46:46Z","receivedAt":"2008-03-25T13:46:46Z","isPatch":false,"sender":{"key":"rogersoares@intelinet.com.br","avatar":null},"body":"\nShawn O. Pearce escreveu:\n> Hmm. How long does C Git take for \"git rev-list HEAD >/dev/null\" ?\n> I have thus far only tuned the lower level machinary, and there\n> may still be tuning left there, but I _really_ have not tried to\n> tune the plotting portion yet.\n> \nI'll do that when I get back home, but I think it should be fast. At \nleast gitk was showing the repo fast enough, from calling it from the \ncommand line and gitk stoping visible activity, I'd say around 2 or 3 \nseconds.\n\nMaybe my problem was with the plotting part. I was running on linux.\n\n> Another thing is how many pack files/loose objects do you have?\n> The loose objects are harder to access, and jgit is currently\n> lacking some of the pack search tricks that C Git uses to get\n> good performance. As such all of my testing has been working on\n> a fully packed repository that has exactly one packfile in it,\n> with no alternates.\n> \nI made a clone of it and never changed it. Don't recall making fetches \neither, so it should be in good shape. I can confirm later.\n\n> Oversight/planned loss of feature. I'm a strong believer of showing\n> the commit message *exactly* as recorded, which means don't do\n> line wrapping of it. Things like character encoding translation\n> and indenting the left side 2-4 spaces to keep it unambiguous from\n> headers is fine when showing it to a human, but otherwise it should\n> match what the user wrote.\n>\n> I forgot to offer a wrap option. If we do enable line wrapping I\n> think we should give the user a way to toggle it on/off for the\n> message area viewer so that if line wrapping is enabled and its\n> borking the current message (e.g. a nice pretty ASCII diagram)\n> you can disable it.\n> \nI understand that you guys use a lot of ASCII art and wrapping can mess \nthis. But here we track more things in bugzilla and there's some \ncopy&pasting going on, so wrapping makes comments more readable. \nCurrently it's a toogle preference in the local toolbar menu (like the \nCVS plugin).\n\nI left the comment on the right side because it's easy to set/unset \nwrapping for the whole viewer, and also for consistency with the CVS/SVN \nplugins, I still use them :)\n\nMy last patches also added the changed files in the left pane as text. \nThe next step would be to add links. Before doing this I thought about \nadding a table there (like what you did) but I chose text with links \nbecause of copy&paste, I find it convenient to paste selected commit \ninfo into IM or email.\n\n[]s,\nRoger.\n"},{"id":"73067","messageId":"200803252048.48531.robin.rosenberg@dewire.com","threadId":"12837","inReplyTo":"47E90246.3030509@intelinet.com.br","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg@dewire.com","sentAt":"2008-03-25T19:48:48Z","receivedAt":"2008-03-25T19:48:48Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"Den Tuesday 25 March 2008 14.46.46 skrev Roger C. Soares:\n> I understand that you guys use a lot of ASCII art and wrapping can mess\n> this. But here we track more things in bugzilla and there's some\n> copy&pasting going on, so wrapping makes comments more readable.\n> Currently it's a toogle preference in the local toolbar menu (like the\n> CVS plugin).\n\nIt seems to me ASCII art should be auto-detectable... Maybe enough to \nmake the wrap flag unneeded in most cases. (wrap/nowrap/auto). At first\nI was thinking about looking for special chars, but then it may be simpler\nand just as useful to look for comment lines start with spaces ane a few\nspecial characters.\n\nTry this command: git log | sed 's/^ [\\t |\\\\\\/>]/| /' | less. It seems \nto detect lines that I do not want wrapped pretty well.\n\n-- robin\n"},{"id":"73094","messageId":"47E9A8BE.4010606@intelinet.com.br","threadId":"12837","inReplyTo":"20080325053649.GE4759@spearce.org","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Roger C. Soares","fromEmail":"rogersoares@intelinet.com.br","sentAt":"2008-03-26T01:37:02Z","receivedAt":"2008-03-26T01:37:02Z","isPatch":false,"sender":{"key":"rogersoares@intelinet.com.br","avatar":null},"body":"Shawn O. Pearce escreveu:\n> Hmm. How long does C Git take for \"git rev-list HEAD >/dev/null\" ?\n> I have thus far only tuned the lower level machinary, and there\n> may still be tuning left there, but I _really_ have not tried to\n> tune the plotting portion yet.\n>\n> I did push something out a few minutes ago (b66eae Limit the number\n> of UI refreshes ...) that may help improve performance on larger\n> histories.\n> \n\"git rev-list HEAD >/dev/null\" returns very fast, around 1 sec I'd say. \nMy git clone has 0 loose objects and 1 pack.\n\nI updated from your repo some minutes ago and it's pretty decent now. \nThe history appears very fast, even changing projects, and for the git \nclone the progress bar disapears in around 7 seconds. :)\n\n[]s,\nRoger.\n"},{"id":"73109","messageId":"20080326045244.GH4759@spearce.org","threadId":"12837","inReplyTo":"47E9A8BE.4010606@intelinet.com.br","subject":"Re: faster egit history page and a pure java \"gitk\"","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-03-26T04:52:44Z","receivedAt":"2008-03-26T04:52:44Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Roger C. Soares\" wrote:\n> Shawn O. Pearce escreveu:\n> >Hmm. How long does C Git take for \"git rev-list HEAD >/dev/null\" ?\n> >I have thus far only tuned the lower level machinary, and there\n> >may still be tuning left there, but I _really_ have not tried to\n> >tune the plotting portion yet.\n> >\n> >I did push something out a few minutes ago (b66eae Limit the number\n> >of UI refreshes ...) that may help improve performance on larger\n> >histories.\n> \n> \"git rev-list HEAD >/dev/null\" returns very fast, around 1 sec I'd say. \n> My git clone has 0 loose objects and 1 pack.\n\nOK, so its well packed and C Git behaves nicely. :)\n\n> I updated from your repo some minutes ago and it's pretty decent now. \n> The history appears very fast, even changing projects, and for the git \n> clone the progress bar disapears in around 7 seconds. :)\n\nSo it must have been the massive flurry of UI updates that I used to\nbe doing during revision walking. I backed it off to at most 4 times\nper second, which seems to help.\n\nFWIW I just pushed another update out:\n\n * re-activates the old preferences for hiding/showing the commit\n message and file list;\n\n * word wrap setting for the comment viewer area;\n\n * saves the geometry (split pane positions) of the history page\n in a hidden preference;\n\n * copy and select all global actions (Edit->Copy aka Ctrl-C) now\n works to copy:\n - selected text in comment area;\n\t - selected path names in the file list;\n\t - commit SHA-1s of selected commits in DAG;\n\n * the window cache is now managed by Eclipse workspace settings\n when inside Eclipse;\n\n * the window cache now defaults to 8k/10m/10m/no-mmap as that is\n working very well for me on multiple systems;\n\n * global workspace preferences (Team -> Git) now shows the history\n preferences and the window cache settings\n\n-- \nShawn.\n"}]}