> > I'm trying to figure out why I'm seeing such poor user interface
> > performance with Subclipse. I was originally using v1.2
> without any
> > problems, and recently updated to 1.4. Specifically:
> >
> > SVN Team Provider Core: 1.4.4
> > Subversion JavaHL: 1.5.2
> > Subversion Client Adaptor: 1.5.1
> >
> > All inside Eclipse 3.3.1.1 on Windows XP.
> >
> > The "SVN interface" on Windows / Preferences / SVN says
> "JavaHL (JNI)
> > 1.5.2 (r32768)" (that's the only choice)
> >
> > Here are the symptoms:
> >
> > If I am connected to the network, any time I right-click on my
> > project, intending to bring up the "Team" menu, there is a very
> > noticeable delay before the menu is presented. I observe network
> > activity while this is going on. If I disconnect from the network,
> > the delay goes away. I have two projects open right now inside
> > Eclipse, and the delay seems to be somewhat longer on the larger
> > project (the project with the greater number of files) but
> it's easily three seconds on the smaller project.
> > The label decorations are very slow to update. By very
> slow, I mean
> > minutes
> > - and some time they don't update at all. Files that I
> change don't
> > get visibly tagged as changed for a very long time, and if I commit
> > files via the Team Synchronization perspective, the "it's been
> > changed" decoration stays around for a long time. Many of
> the files
> > never get the "version date and user" annotation to the
> right of the file names.
> >
> > I have checked the .log file in the .metadata area of my workspace,
> > and it shows nothing obviously subclipse-related. I get a bunch of
> > exceptions from mylyn when I start Eclipse (threads timing
> out waiting
> > for other threads) which include references to
> > org.eclipse.ui.internal.decorators.LightweightDecoratorManager and
> > org.eclipse.ui.internal.decorators.DecorationScheduler
> which vaguely
> > suggests that something's unhappy there - possibly that's involved
> > somehow even though nothing from Subclipse is explicitly
> mentioned?
> > Otherwise, once the workspace is up and running, I don't get any
> > further entries in the .log file.
> >
> > I had none of this kind of behavior before updating to the current
> > release of SVN - with the older version I got almost instantaneous
> > update of the label decorations, and didn't see the "right-click"
> > delays. I'm not sure why the right-click operation would be
> > triggering any network activity anyway.
> >
> > I also use SmartSVN, which doesn't have any performance
> issues that I
> > can see - that suggests that it has nothing to do with my
> connection
> > to the repository.
> >
> > I also use Carbide.c++, which is also based on Eclipse. When I
> > updated its version of Subclipse to 1.4.2 it also developed
> similar behavior.
> >
> > If anyone can suggest what I can do to figure out what's
> going on, I
> > would be grateful.
>
> All of these things are symptoms of slowness in determining
> the status of files. Something you might try is Team >
> Cleanup. If your SVN metadata is out of synch with the
> current file timestamps this will cause SVN to do a byte by
> byte compare of the file to see if it is modified. It is
> also possible something is not right about your WC in
> general. Have you tried a new checkout using the latest Subclipse?
> SVN 1.5 has a new WC format and maybe something is wrong
> about it when it auto-updated?
>
> I cannot think of why it would contact the network.
> Something that comes to mind is that the WC is supposed to
> hold the URL of the repository root. I noticed a while back
> that when I shared a new project the Team > Add/Commit
> process did not populate this value. I reported this bug to
> SVN. Perhaps if we get a null for this value we contact the
> repository to get it? A fresh checkout would solve this
> problem if that is the case.
>
> Generally, Subclipse performance in 1.4 should be
> significantly faster than 1.2, with the exception being
> certain repository operations that are now slower with SVN
> 1.5. This stuff should all be purely local though.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
>
Mark -
Thanks for the thoughts. I did a bit of experimentation based on what you
suggested.
"Team > Cleanup" didn't help. There wasn't any noticeable difference before
or after.
I decided to try checking out a project directly through Eclipse. What I
had done before was to check out the project using SmartSVN and then import
it into Eclipse. (I won't go into the reasons why.) When I went to do
this, I discovered that, for some reason, there were about a billion
"Repositories" listed in the Repository view - it looks like virtually every
file in every project was listed as a "Repository". I thought maybe that
was the problem (maybe it was trying to check thousands of repositories),
but when I got that cleaned up, things still weren't happy.
In any event, I found the magic by checking out the project via Subclipse.
After getting the respository stuff cleaned up, I removed one of the
projects from my workspace, and then checked it out directly through
Eclipse/Subclipse. That project was now nice and snappy, while the other
project (originally checked out via SmartSVN) still showed the slow-down
behavior. Ah ha!
I was kind of surprised that the two tools wouldn't "play nice" with one
another, so I did a little careful poking around in the .svn folders. The
thing I found that was different was that the SmartSVN-checked-out stuff
used a repository URL that looked like:
https://host:443/path
while the Subclipse stuff used the path
https://host/path
Given the "https," the "443" was kind of redundant, so I went back into
SmartSVN and did a Modify>Relocate to shift my other project (the one that
was still slow) from https://host:443/path to https://host/path. (The 443
was there originally because it was in the URL I was given by my SVN
provider - I just copied and pasted without thinking about it.) Lo, and
behold, when I then re-imported that project back into Eclipse, now it was
nice and snappy as well.
So, it appears that the issue was one of two things: Either SmartSVN
doesn't check out projects properly (corrupt metadata or something) if you
have both "https" and "443" in your repository URL or (more likely, I think)
Subclipse itself gets unhappy if it sees both. I noted that Subclipse would
not let me define both https://host:443/path and https://host/path as
repository profiles - it recognized that the two were the same.
In any event, problem solved. Thanks for the suggestions Mark - it put me
on the right track.
Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: users-help_at_subclipse.tigris.org
Received on 2008-09-18 02:43:56 CEST