Hi Noel,
I was the one who changed this code to using a linked hash set (a long
time ago). From what i remember, the sole reason for keeping the set is
to keep a list of resources that need refreshing. The order is
important because of the way eclipse handles derived resources (the svn
metadata directories become visible and are not flagged as derived). A
better solution would be to try and figure out the common ancestors for
the resources and refresh them with a depth of infinite. The resources
can be refreshed in any order because they should be disjoint (the
problem occurs when children are refreshed before their parent). It
would reduce disk access in a few cases too.
I might be able to knock up a patch for this tonight for you to try out
(it may be slower for smaller number of resources though)
Cheers,
Brock
Noel Grandin wrote:
> 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 10:16:46 2006