[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [Subclipse-users] Slowness on Checkout, Synchronize

From: Alexander Kitaev <alex_at_tmate.org>
Date: 2006-04-13 17:55:19 CEST

Hello Andy,

> Things we've tried to fix it, nothing worked except #3 and we
> don't want to do that:
> 3) Using SSH (we don't really want to lose the LDAP auth, though)

I do not think syncronized methods is what cause slowness. Actually, there
are mostly no synchronized methods in JavaSVN, you're probably talking about
higher-level wrapper (like SVNClientSynchronized class or something in the
svnClientAdapter code). The fact that checkout works faster over ssh
comparing to http means that slowness may be caused by the apache
configuration. BTW, how much faster ssh access comparing to http one? Also,
what is the difference in performance between cli and Subclipse when http
protocol is used?

On the other side you wrote that cli operations are faster than those with
Subclipse. The reason could be Eclipse itself that performs some
post-checkout operations like building checked out project.

Regarding JavaSVN and JavaHL - latter could be slower, as JNI calls add
certain overhead.

Alexander Kitaev,
TMate Software,
http://tmate.org/
http://jetbrains.com/tmate/

> -----Original Message-----
> From: Andrew Goodnough [mailto:Andrew.Goodnough@wicourts.gov]
> Sent: Thursday, April 13, 2006 17:43
> To: users@subclipse.tigris.org
> Cc: MaryJane Taylor; Tom Heiber-Cobb
> Subject: [Subclipse-users] Slowness on Checkout, Synchronize
>
> I've got some users reporting slowness on Checkout and
> Synchronize in Subclipse. (This is not related to the
> Subclipse 1.0 release.) Here is his comment about Synchronizing:
>
> ==user comment==
> Here are my ball park measurements.
> Click on "Synchronize with Repository";
> Seems to take about 45 seconds before (what I think is)
> authentication to occur (Status label in lower right corner
> of Eclipse reads "Synchronizing (0%)") Synch progress bar pops up.
> Takes about another 40-45 sec. to finish (a little less if
> nothing new to report).
> In addition, anecdotal "evidence" from co-workers seems to
> correspond with my experience.
> ==end user comment==
>
> We're authenicating to an LDAP server thru Apache WebDAV.
> Apache and SVN are on the same SUSE Linux box. The CLI is
> very quick on all operations so we think this is a problem at
> the Subclipse level.
> Checking out one of our applications is also slow from
> Subclipse and takes 11.5 min every time. I've been told it's
> a large project by SVN standards - 20046 items, totalling
> 239.5 MB. It also was brought over with 4-5 years of history
> (branches/tags, everything) from CVS using cvs2svn.
>
> Things we've tried to fix it, nothing worked except #3 and we
> don't want to do that:
> 1) Turning off indexing of the drive on Windows clients
> 2) Switching the Subclipse preferences to use JavaHL instead
> of JavaSVN.
> 3) Using SSH (we don't really want to lose the LDAP auth, though)
> 4) Looking through the Subclipse code. I noticed that most
> of the core methods in the JavaSVN code (checkout, update)
> are synchronized. My theory was that it was the synchronized
> Java wrapper around the "fast" C libraries that was slowing
> things down. But, if this is true, using the JavaHL setting
> should have bypassed these methods and made them faster,
> which it didn't.
>
> Thanks in advance for any ideas.
>
> Andy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
> For additional commands, e-mail: users-help@subclipse.tigris.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Thu Apr 13 17:55:52 2006

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.