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

Re: [Subclipse-dev] SVNActiveChangeSetCollector listens for changes in derived folders

From: Mark Phippard <markphip_at_gmail.com>
Date: Thu, 13 Nov 2008 09:21:40 -0500

On Thu, Nov 13, 2008 at 9:29 AM, Martin Ko <Martin.Koci_at_aura.cz> wrote:
>
> 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.

I am not saying you cannot refactor the code, I am explaining why we
did not make it this way to begin with. You also have to factor in
that we do not have any tests that are going to help identify
regressions.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2008-11-13 15:21:50 CET

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

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