Topic: about speed of searching objects in list

[gile]

It is also possible to implement your algorithm with HashSetS. It has some overheads (i.e. building one more HashSet with some more conditions) but should be faster then using Lists.

Code - vb.net: [Select]

1. Public Shared Sub SelectionChanged()
2.    Dim curveType = RXClass.GetClass(GetType(Curve))
3.  
4.    Dim candidates = New HashSet(Of LengthAreaObject)( _
5.            From id In get_selected_oids() _
6.            Where id.ObjectClass.IsDerivedFrom(curveType) _
7.            Select New LengthAreaObject() With { .oid = id })
8.    
9.    Dim itemsToKeep = New HashSet(Of LengthAreaObject)( _
10.            From o In lengthAreaList
11.            Where o.keep_this_one OrElse candidates.Contains(o)
12.            Select o)
13.            
14.    itemsToKeep.UnionWith(candidates)
15.  
16.    lengthAreaList.Clear()
17.    lengthAreaList.AddRange(itemsToKeep)
18. End Sub

[nekitip]

Gile, I'm amazed that you try to help, cause that is a good deed, not found regulary, and i feel somewhat guilt because of that, but I feel that you have not read carefully enough, OR it was me to blame that I have put way too mouch text and too little code, and in this way may have misguided you. However I have pointed almost every time that I'm really intereseted in a FASTER ways of finding list of add objects, and removed objects:

need to remove the ones not currently in selection and add the new ones

I need something like "objects added to selection" and "objects moved from selection"

Now, rembember - i needed "add list" and "remove list".

The thing about code I posted is that it is oversimplified so it can be easier to understand, with everything needed to know is that I really needed 2 lists: added and removed objects. I admit that this is not a good design, but this code is a relict from acad 2008 and I don't have the time RIGHT NOW to rewrite new, since it works. The list at the end you see is actually far more complex and does heavy handleing of hooking events, reading initial values, notifing other interesed parties hooked to its own events... basically holder for all the objects. So if you (in this scenario) do make "list = anything" - this means - forget everything, reset list, and let all the items, like baloons with cut strings to go to the roof and left waiting for garbage collector, and we know this cannot be done safely in ACAD.
The first listing you posted is fast, but it does "=" thing.
The last one you posted is about the same fast as the code I posted as "my final" (this also runs about 1 sec on 10000 objs) but yours is cleaner, and thus better. But since "add items" is also somewhat expensive, I guess that if we had a separate list of only removed items, and added items, it would run fastest. My goal was to make it in linq.

to ilustrate: the actions are
form LIST1 (of type in this case, user selected object ids)
1) add items to MYLIST(of different type) (if this item is not already here), and let list perform "action" on every new later in bulk mode (not seen in this code)
2) remove items from MYLIST, not found in LIST1 (but not the ones we would like to keep), and let list perform "actions" in bulk mode

[gile]

Sorry if I misunderstood.

All i wanted to say was: if you want to improve your code performances, use the right collection for the job.
HashSet<T> are more efficients than List<T> for sets (unsorted collections with no duplicated items) operations and provides usefull methods for this (IntersectWith(), ExceptWith(), UnionWith(), ...).

Look attentively to the last code I posted (reply #15)
The LengthAreaObject instance contained in 'itemsToKeep' HashSet refer to the same objects as those contained in 'lengthAreaList'.
At the end of the code, the 'lengthAreaList' is cleared (not set to null or Nothing) and filled with the 'itemsToKeep' items (which are the same objects as those which were previously in this list) plus the ones in 'candidates' which were not already in 'itemsToKeep' (the UnionWith() behaviour).
So none link is lost.

PS: IMO, Linq isn't more efficient, especially if you commit all the queries with ToList().

[WILL HATCH]

...
Also, if used toint32, it doesnt work (maybe because i have 64 machine), and this potentially complicates things if it is to be used in practice.
...

Strongly recommend against converting this type for comparison as it is volatile across platforms.  Since IntPtr is a base type in .net I would not expect to see its direct comparison suffer significantly.  Let me know if I am wrong here.

My pattern for checking is typically ObjectId.Handle.Value FYI