Yes, code maintainability is in question. But the only true logic in
TeamPrivateListener is following if command:
if (provider.isAdminDirectory(resource.getName())) {
if (handleSVNDir((IContainer)resource)) {
return false;
}
}
method handleSVNDir is an utility method and can be static too.
Leftover is the visiting of tree of deltas.
Performace is the reason why I'm profiling this. I have workspace with
more than 100 000 java sources and rebuild of whole workspace takes 4-6x
more time with subclipse installed (all projects are managed with svn).
The biggest 'deliquent' is SubscriberResourceCollector from
team.internal (about 70% of CPU time), but TeamPrivateListener and
FileModificationManager are eating the rest (and JDT compiler itself, of
course).
After modification all of these IResourceChangeListeners for skipping
derived folders compilation takes only 2x time more than without
subclipse.
Even with this "better" result there is still much calling of
IResourceChangeListener.resourceChanged(IResourceChangeEvent) and delta
processing.
This is double true for projects with hiearchical layout (maven layout).
That layout means double occurences of all files in workspace. See
http://jira.codehaus.org/browse/MNGECLIPSE-635 for example.
Mark Phippard píše v Čt 13. 11. 2008 v 08:46 -0500:
> On Thu, Nov 13, 2008 at 8:34 AM, Martin Kočí <Martin.Koci_at_aura.cz> wrote:
>
> > I have more informations about this problem.
> >
> > There are at least three IResourceChangeListeners running during
> > workspace build.
> >
> > 1) FileModificationManager from org.tigris
> >
> > 2) TeamPrivateListener from org.tigris
> >
> > 3) SubscriberResourceCollector from org.eclipse.team inicialized from
> > Subclipse
> >
> > All three are processing the same tree of deltas (same
> > IResourceChangeEvent instance). Visiting resources deltas is cheap but
> > not completely free - best performace can be achieved with one resource
> > change listener per subclipse.
>
> It is certainly something we have considered, but any performance
> benefit would seem to be marginal at best and the tradeoff is code
> maintainability.
>
> > I propose:
> >
> > - Merge FileModificationManager and TeamPrivateListener into one
> > SubclipseResourceChangeListener
> >
> > - Modify SubclipseResourceChangeListener to skip derived resources
> >
> > - recode all about ChangeSet for SubclipseResourceChangeListener and get
> > rid of org.eclipse.team.internal
> >
> >
> >
> > Questions:
> >
> > Are there any public APIs for Eclipse Change Sets feature? I seems many
> > of them are only internal.
>
> The Change Set stuff is not public API and apparently Eclipse does not
> plan to ever change this. There are open issues in Eclipse bugzilla.
>
> > How is Eclipse Change Set related to Changelist from subversion 1.5?
>
> They pre-date the feature. We have not updated Subclipse to co-exist
> with those new API's yet:
>
> http://subclipse.tigris.org/issues/show_bug.cgi?id=635
>
> There are some differences. For example, SVN does not allow folders
> to belong to a changelist and Eclipse does. Also, SVN does not allow
> you to set a comment on a Changelist. So we could not rely on SVN
> exclusively to store the changelist information. Of course you also
> cannot have unversioned items in an SVN changelist.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-11-13 15:14:00 CET