Converting to generics

[Frank Rizzo]

Given the inneficiencies of ArrayList and Hashtable on 64-bit systems, I
am converting them to List<> and Dictionary<> respectively. It's a
pretty massive system, so there are a lot of casts. For instance.

ArrayList aaa = new ArrayList();
aaa.Add(new Customer());
aaa.Add(new Customer());
aaa.Add(new Customer());

Customer c = (Customer) aaa[0];

With generics, it would be like this:

List<Customer> aaa = new List<Customer>();
aaa.Add(new Customer());
aaa.Add(new Customer());
aaa.Add(new Customer());

Customer c = aaa[0]; //e.g. without the cast

But, given that I simply changed declarations from ArrayList to List<>,
there is still a lot of code that has a cast, even though the cast is
from a strongly typed list:

Customer c = (Customer) aaa[0];


So changing declarations to generics was pretty easy, but the there are
about a zillion casts in the system. So I have 2 questions.

1. Is the compiler smart enough take out the unnecessary casts?
2. Is there a setting in VS2005 that will show me the unnecessary casts
when compiling?

Thanks.

 

[Alberto Poblacion]

1. Is the compiler smart enough take out the unnecessary casts?

To answer this, and other similar questions, you can compile the code
with and without the cast and then use ILDASM.exe to examine the MSIL that
the compiler has generated. This will demonstrate wether the cast has been
optimized away or not.

 

[Nicholas Paldino [.NET/C# MVP]]

Frank,

I would think that the compiler could be smart enough to do this, but to
be sure, why not compile that code and look at the IL? You should be able
to tell pretty quickly if a cast is taking place.

As for finding the unnecessary casts, there is no such setting to do
this for you. You will have to find all the instances of (Customer) and
then remove them manually.

What you could do is a find and replace across all of your projects and
remove (Customer). Then, when you compile the project, you will see where
the compiler tells you that you have a type mismatch (because one is
assuming that you are casting from an interface or something like that).

Finally, the Hashtable and ArrayList are inefficient due to their
generic counterparts because of boxing issues, not because they are being
run on 64 bit systems. If the Customer type is a value type, and you have a
number of these operations taking place, you will see a performance
enhancement. You will see a little bit of a performance enhancement with
reference types, but not as much.

With reference types you still want to make the push to use generics so
you can get compile-time checking of your type usage (as opposed to finding
errors at runtime because of invalid casts).

Hope this helps.

 

[Frank Rizzo]

To answer this, and other similar questions, you can compile the code
with and without the cast and then use ILDASM.exe to examine the MSIL
that the compiler has generated. This will demonstrate wether the cast
has been optimized away or not.

Yep, the compiler is smart enough. I just checked.

 

[Frank Rizzo]

Frank,

Finally, the Hashtable and ArrayList are inefficient due to their
generic counterparts because of boxing issues, not because they are being
run on 64 bit systems. If the Customer type is a value type, and you have a
number of these operations taking place, you will see a performance
enhancement. You will see a little bit of a performance enhancement with
reference types, but not as much.

No, there are inefficiencies in the ArrayList on many fronts from boxing
issues to memory issues. The comparison in memory usage in the link
below shows more than 4x improvement for using List<t> over ArrayList on
the 64-bit system.

http://blogs.msdn.com/joshwil/archive/2004/04/13/112598.aspx

 

[Marc Gravell]

What you could do is a find and replace across all of your projects and

remove (Customer).

Just a note: watch out for disambiguations, specifically when the cast
is as a parameter to an overloaded method; i.e. if you have
SomeFunc(object) and SomeFunc(Customer), and you remove a cast it
might start calling the wrong method, which could (as an example) mean
calling itself iteratively.

Not that I still have bitter memories or anything...

Marc

 

[Nicholas Paldino [.NET/C# MVP]]

Yes, more memory is required for each of the object references. If it
is a value type, then yes, you are going to have 64 bits for each object
reference for each boxed value type instance. For reference types, you are
going to have 64 bits for each of the object references as well, but thats
an issue with ^every^ object reference that you have in the app.

Now, this is an opinion, and goes a little bit beyond the scope of the
post, but it's my belief that this is something that doesn't matter in the
initial implementation of a design for a system. It's something you have to
be concerned with in the performance evaluation phase. I wouldn't even
worry about this initially (well, mostly because it's a non issue because
I'd be using the Generic versions of the data structures, but if I couldn't
use them, then I still wouldn't worry) because in a 64-bit environment, I am
going to have a virtual address space which is exponentially larger than the
address space on a 32-bit machine. So yes, while object references will
take up 64 bits, which is double the size of references on a 32 bit machine,
I'm not too concerned, because the virtual address space is going to be that
much larger.

Of course, we all know that virtual address space doesn't correspond to
physical memory, but going back to the second sentence of the first
paragraph, I feel that you are typically going to have 64-bit processors in
server environments, and in that case, you are going to have gobs of
physical memory to back up the virtual address space, which leads me to
believe it is a non-issue, at least in the initial implementation of a
design.

 

[Ben Voigt]

Finally, the Hashtable and ArrayList are inefficient due to their

generic counterparts because of boxing issues, not because they are being
run on 64 bit systems. If the Customer type is a value type, and you have
a number of these operations taking place, you will see a performance
enhancement. You will see a little bit of a performance enhancement with
reference types, but not as much.

Eliminating the run-time type check incurred by a downcast is pretty
significant.

 

[Jon Skeet [C# MVP]]

Eliminating the run-time type check incurred by a downcast is pretty
significant.

In how many situations? Usually when I fetch an object from a list, I
then want to *do* something with it - and that "something" is likely
to take significantly longer than the cast.

Of course, it depends on exactly how significant something needs to be
in order to be called significant, but for the vast majority of
programs I wouldn't expect to see much improvement in performance due
to just removing the runtime check.

Jon

 

[Frank Rizzo]

Yes, more memory is required for each of the object references. If it
is a value type, then yes, you are going to have 64 bits for each object
reference for each boxed value type instance. For reference types, you are
going to have 64 bits for each of the object references as well, but thats
an issue with ^every^ object reference that you have in the app.
Now, this is an opinion, and goes a little bit beyond the scope of the
post, but it's my belief that this is something that doesn't matter in the
initial implementation of a design for a system. It's something you have to
be concerned with in the performance evaluation phase. I wouldn't even
worry about this initially (well, mostly because it's a non issue because
I'd be using the Generic versions of the data structures, but if I couldn't
use them, then I still wouldn't worry) because in a 64-bit environment, I am
going to have a virtual address space which is exponentially larger than the
address space on a 32-bit machine. So yes, while object references will
take up 64 bits, which is double the size of references on a 32 bit machine,
I'm not too concerned, because the virtual address space is going to be that
much larger.

The problem is not the virtual address space, it's physical memory. My
application chews through a lot of memory. In 32-bit mode it would take
up to 1.5GB. When I recompiled it as is for AnyCPU and ran it on a
64-bit box, the memory usage doubled. That's The app is running on a
box with 6GB of RAM that also has SQL Server on it, so all of a sudden
processes got shifted into the paging file, which slowed everything to a
crawl.

Of course, we all know that virtual address space doesn't correspond to
physical memory, but going back to the second sentence of the first
paragraph, I feel that you are typically going to have 64-bit processors in
server environments, and in that case, you are going to have gobs of
physical memory to back up the virtual address space, which leads me to
believe it is a non-issue, at least in the initial implementation of a
design.

It's not the initial implementation. Things were good in the 32-bit
land (e.g. SQL Server 2000 and my app in 32-bit mode), however, once the
boxes got upgraded to 64-bit (e.g. Win2003 R2 64-bit and SQL Server 2005
64-bit), all of a sudden Sql Server needs more ram to operate properly
and so does my app (at least in 64-bit mode).

So for now, while I rip out ArrayList objects, the app keeps operating
in 32-bit mode on a 64-bit machine.

Regards

 

[Mark Wilden]

ReSharper displays unneeded casts as warnings.

///ark