Red Hat Bugzilla – Bug 151832
CVS checkout really slow
Last modified: 2007-11-30 17:11:02 EST
I am experimenting with using gcj/gij to run eclipse using the gcj packages from
the Fedora development repository.
One thing I have noticed when using gij or gcj-compiled eclipse is that CVS
checkouts seem really, really slow. I am connecting to dev.eclipse.org
/home/eclipse as anonymous (pserver). Is it possible that something at the
gcj/gij level is making network connections slow down?
To clarify further, I am testing with eclipse I20050315-1100.
Moving to devel. Assigning to me.
Really assigning to me.
During checkout, the gij process is spinning the CPU.
This is CVS using ext, right? It's over ssh?
No, using pserver.
Created attachment 114297 [details]
I've attached an oprofile report of a pserver checkout of gnu-crypto.
I started profiling just as the cvs co started, and stopped as soon as it
I haven't look at the report closely, other to note that we're spending the
vast majority of our time in the kernel - presumably waiting on stuff. I also
don't understand why we're trying to load classes here.
I've been working on this 'cause it was really bugging me. My test project was
gnu-crypto . After fighting with oprofile and trying to figure out the cause
of the slow checkouts, I have now come to the conclusion that if we set the
compression level to 3 (or higher, I guess), checkout time is acceptable. Since
I ran into similar problems with Sun's JVM (with gnu-crypto), I'm willing to bet
it's an upstream issue (or at least gnu-crypto exacerbates the issue). I've
opened an Eclipse bug  to see if we can get the default compression set to 3
and if not, to see if there's a way we can set it in our builds.
I'd like to close this as NOTABUG because I get the same behaviour with our
native stuff as with Sun's JVM.
I'm wondering if this was the same effect as bug 161483. Billy/others, if you
get time, can you try the packages that will hit rawhide today (-15)?
I've noticed this myself now. We do indeed take longer than the Sun JVM to
check things out of CVS regardless of compression level.
Surely this one is now fixed.
I don't use the Sun JVM for much other than testing sometimes so I can't really
verify. Ben, can you perhaps take a look at this? Maybe we can get some data
out of the automated tests or something.
(In reply to comment #10)
>I'm wondering if this was the same effect as bug 161483. Billy/others, if you
>get time, can you try the packages that will hit rawhide today (-15)?
I think we can close this bug now. Andrew, what do you think?
Sure, and if checkout time bothers people, we can re-open.