Hi
Why are you using a set? Does the notification handling potentially
notify about the same file multiple times?
Why a LinkedHashSet? Do you really need to traverse it in insertion order?
ArrayList is more efficient, particularly if you can size it correctly
at instantiation.
Where ArrayList falls down is if you don't know the size, and it has to
copy it's internal array several times.
Otherwise, jakarta-commons-collections and jakarta-commons-primitives
have a whole slew of optimized collections classes.
Cheers,
Noel
Mark Phippard wrote:
>A colleague of mine discovered a problem in Subclipse when committing (in
>this case adding) thousands of files in one commit. The behavior is that
>it would run for hours and never even get to the point of sending the
>commit to the server. It was still outputting the Adding ... messages to
>the console. Over time, it takes longer and longer for each adding
>message to the console.
>
>Doing the commit via the command line the whole thing finishes in about 10
>minutes.
>
>Looking at our code it looks like this is caused by our notification
>handling, and as near as I can tell would have always been in Subclipse.
>This is not a new problem. What I see is that we are collecting the items
>that commit is notifying us about in a Set, specifically a LinkedHashSet.
>This is so that when the commit is finished we can then process this Set
>and notify Eclipse that all of these items have been committed.
>
>So the problem must be in the scalability of the LinkedHashSet. Eventually
>the JVM runs out of memory and crashes, or at a minimum it gets
>progressively slower in adding the items to the Set.
>
>Ideally someone could point me to a more efficient class we could use that
>would be capable of scaling up to hold thousands of IResource objects
>without crashing the JVM.
>
>I am looking at the OperationManager class in the core plug-in.
>
>Thanks
>
>Mark
>
>
>
>
>
>
>
>
>_____________________________________________________________________________
>Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
>_____________________________________________________________________________
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
>For additional commands, e-mail: dev-help@subclipse.tigris.org
>
>
>
>
NOTICE: Please note that this email, and the contents thereof,
are subject to the standard Peralex email disclaimer, which may
be found at: http://www.peralex.com/disclaimer.html
If you cannot access the disclaimer through the URL attached
and you wish to receive a copy thereof please send
an email to email@peralex.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: dev-help@subclipse.tigris.org
Received on Fri Feb 17 07:20:43 2006