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] oprofile report 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 finished. 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 [1]. 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 [2] 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. [1] :ext:anoncvs.org:/cvsroot/gnu-crypto [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=95697
I'd like to close this as NOTABUG because I get the same behaviour with our native stuff as with Sun's JVM. Thoughts?
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.
Blah blah.
(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)? askldfjlsdf sdfjsdfk sfd
I think we can close this bug now. Andrew, what do you think?
Sure, and if checkout time bothers people, we can re-open. Closing.