From: "Shawn O. Pearce" <spearce@spearce•org>
To: "Roger C. Soares" <rogersoares@intelinet•com.br>
Cc: git@vger•kernel.org, robin.rosenberg@dewire•com
Subject: Re: [EGIT PATCH 1/4] Change history page table to SWT.VIRTUAL.
Date: Tue, 1 Apr 2008 00:12:03 -0400 [thread overview]
Message-ID: <20080401041203.GR10274@spearce.org> (raw)
In-Reply-To: <47F1B1D9.3090209@intelinet.com.br>
"Roger C. Soares" <rogersoares@intelinet•com.br> wrote:
>
> >Hmm. I didn't notice that, but at this point its so damn fast for
> >me that I don't have the reflexes to really try and use the table
> >before GenerateHistoryJob is complete. I'll have to add some sleeps
> >in there to make it slow down its work and see if I can reproduce
> >what you are describing.
>
> Yep, I noticed it while debuging and don't think it's very important.
> I'm very happy with the current speed and it's also almost instant to
> me. I think the lazy provider could be of some help in case someone is
> reading from a slow nfs partition or something like that. It's very
> border case thought.
Actually I think the trick to use there is the "early output
and restart" that C Git's rev-list and gitk learned about two
months back. We don't do this in jgit yet and that means we have
to produce _all_ commits before we can topologically sort them and
return even the first commit.
We should be able to produce results immediately and then force
a reset and redraw of the table when we find the rare cases where
topological sorting gets violated by honoring the standard commit
date ordering.
There aren't many such cases in git.git or linux-2.6.git. They only
happen if clock skew is enough that folks are able to create multiple
commits at the same time that are out of order according to topology.
And remember that in the GUI we do wind up redrawing the table anyway
as we add new items to the end of it. So its really no big deal
to just reset everything and restart when we find the violations.
Its on my list of things to add to the jgit machinary, but I'm also
looking to get push[*1*] and merge implemented. I am reasonably
happy with the performance of the History view, as its actually
now usuable on real projects. So its time to add new features,
rather than optimizing old ones.
[*1*] Hopefully this is a successful GSoC 2008 project. ;-)
--
Shawn.
prev parent reply other threads:[~2008-04-01 5:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-30 15:18 [EGIT PATCH 1/4] Change history page table to SWT.VIRTUAL Roger C. Soares
2008-03-31 5:34 ` Shawn O. Pearce
2008-04-01 3:25 ` Roger C. Soares
2008-04-01 3:36 ` Shawn O. Pearce
2008-04-01 3:54 ` Roger C. Soares
2008-04-01 4:12 ` Shawn O. Pearce [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080401041203.GR10274@spearce.org \
--to=spearce@spearce$(echo .)org \
--cc=git@vger$(echo .)kernel.org \
--cc=robin.rosenberg@dewire$(echo .)com \
--cc=rogersoares@intelinet$(echo .)com.br \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox