From: Linus Torvalds <torvalds@osdl.org>
To: Shawn Pearce <spearce@spearce.org>
Cc: git@vger.kernel.org
Subject: Re: jgit performance update
Date: Sun, 3 Dec 2006 09:45:15 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.4.64.0612030938140.3476@woody.osdl.org> (raw)
In-Reply-To: <20061203045953.GE26668@spearce.org>
On Sat, 2 Dec 2006, Shawn Pearce wrote:
>
> With the help of Robin Rosenberg I've been able to make jgit's log
> operation run (on average) within a few milliseconds of core Git.
Very good. Are we any closer to actually having an eclipse plugin then?
Not that I've ever actually used eclipse, but maybe I should try it, just
to see what those strange user-land people actually do. I'll be a
veritable Jane Goodall..
> Walking the 50,000 most recent commits from the Mozilla trunk[1]:
>
> $ time git rev-list --max-count=50000 HEAD >/dev/null
>
> core Git: 1.882s (average)
> jgit: 1.932s (average)
>
> (times are with hot cache and from repeated executions)
Now, the _interesting_ case in many ways is not "--max-count", but the
revision limiter. It _should_ be equally fast, but if you've done
something wrong, it won't be.
IOW, try to find a point far enough back in time to get about the same
number of commits, and then do
time git rev-list <thatpoint>..HEAD >/dev/null
because one of the things you want to handle is ranges, more so than
simple counts. And that is not only the much more common case, it also
triggers a few cases that you probably didn't trigger with the regular
"list the first 50 thousand commits" case.
> One of the biggest annoyances has been the fact that although Java
> 1.4 offers a way to mmap a file into the process, the overhead to
> access that data seems to be far higher than just reading the file
> content into a very large byte array, especially if we are going
> to access that file content multiple times.
That must suck for big packed repositories. What JVM and other environment
are you using?
Also, I have to say, one of the reasons I'm interested in your project is
that I've never done any Java programming, because quite frankly, I've
never had any reason what-so-ever to do so. But if there is some simple
setup, and you have jgit exposed somewhere as a git archive, I'd love to
take a look, if only to finally learn more about Java.
next prev parent reply other threads:[~2006-12-03 17:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-03 4:59 jgit performance update Shawn Pearce
2006-12-03 13:55 ` Robin Rosenberg
2006-12-03 14:19 ` Jakub Narebski
2006-12-03 15:53 ` Robin Rosenberg
2006-12-03 23:06 ` Shawn Pearce
2006-12-03 22:59 ` Shawn Pearce
2006-12-03 17:45 ` Linus Torvalds [this message]
2006-12-03 17:56 ` Jakub Narebski
2006-12-03 22:42 ` Juergen Stuber
2006-12-03 23:39 ` Robin Rosenberg
2006-12-03 23:58 ` Jakub Narebski
2006-12-04 0:46 ` Shawn Pearce
2006-12-04 20:35 ` Juergen Stuber
2006-12-03 22:47 ` Shawn Pearce
2006-12-03 21:55 ` sf
2006-12-03 22:16 ` Shawn Pearce
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=Pine.LNX.4.64.0612030938140.3476@woody.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).