Indie-Resource.com

What is the fastest and best method for comparing two lists for equals. So in other words if number exists in both lists add to a counter.

I know I can loop through on list then do a foreach in that but that seems like a bad way of doing it and I have multiple lists and I am already looping through a list of classes.

I forgot to mention I am using .net 2.0(long story, old server) so intersect will not work.

I would say here you need to experiment, but I would think about two possible roads: sort them, and then go through them in parallel and see if the thing matches, number in list A bigger than in list B check next in list B etc...

Second option would be to put the values in a dictionary or hash table, and then use it to see if they are there.

3rd option would be to use Linq once you kicked some and upgraded your oldies

haha yeah upgrade would be nice as I cannot even use json serialization.

Thanks for the suggestions I will try them out.

What's keeping you on an ancient version of .Net?

Its a long story but has to do with clashing roles and a development dept trying to keep me from shining. I do anyways

Cayle wrote:What's keeping you on an ancient version of .Net?

This is not uncommon in business. For one, there is the cost. For a business to get the latest version of .NET, that means a new round of VS licenses, probably new Windows licenses, etc. Then there is training. While much of .NET remains the same from one version to the next, there are parts that are not backwards compatible, such as sockets, threading and some database access layers. When you have a dev who has been working on the same version of almost 10 years, it can be hard to change and can slow down productivity.

And finally, there is need. In business, a new version is not a reason to upgrade. Cool new features are not a reason to upgrade. Due to the expense of upgrading, there needs to be tangible cost savings in the new version. It also must overcome the actual risk of data and hardware loss to upgrade (this analysis begins to overlap into Project Management).

Jack, I understand this. The product that I work on is one major revision behind (.Net 3), through the dev team is planning on switching to VS2012, .Net 4 and from Version One to Team Foundation (as sprint management tool) in the next release. It is a task that sucks down a lot of man days err weeks. For example, right now, nobody is maintaining the backlog in V1 anymore, but its not online yet in TFS, so I can't use that for the backlog yet either. We also need to be able to handle Office 2012 and we've got a couple of to-date unsolvable problems which can be cracked with asynchronous programming. These are compelling reasons to migrate.

How does .Net handle the installed version .Net being ahead of the app? Does it maintain an older API version for the application? If not, then being 2 major revisions back carries its own risks.

Not sure if this topic is still active, but the question is hard to answer. It depends on what you need to compare, never resort to <n>inner loops, that will kill your performance!

If you try to compare numbers, a sorting algorithm like quicksort is probably your best best, dump all the values on a big stack, perform the quick sort algorithm and check for duplicates ( and remove them, or whatever you need to do ) if you are dealing with objects it`s going to be a bit trickier, there are better sorting algorithms you can use for equality, I believe the generic<T> List has a fair sorting speed when dealing with objects, you`d have to look at specifics though.

Cayle wrote:How does .Net handle the installed version .Net being ahead of the app? Does it maintain an older API version for the application? If not, then being 2 major revisions back carries its own risks.

Right now there are 2 CLRs (sort of). The modern CLR can handle .NET 3.0 and up. The second is a "compatibility" CLR that can run 1.0, 1.1 and 2.0. However, the compatibility CLR is emulated, so it is not 100%, and to my knowledge Microsoft has little interest in fixing it up (very little is done in .NET 1.0 and 1.1 today, and 2.0 is fading fast).

When a new version of .NET is released, the modern CLR is updated to handle the latest release, and there is consideration about relegating the earliest supported version to the compatibility CLR to streamline the modern CLR. 3.0 will likely be a no brainer to move over with the next release, as its only addition was WinFX (WPF, Silverlight, etc.), which has better, sleeker versions in later .NET releases. 3.0 was rarely targeted by application builds, and I am not sure if it was even targetable in VS. If I remember right, the VS targets jumped right from 2.0 to 3.5, and 3.0 could only be targeted by manually altering meta data.