Dictionary Throws OutOfMemoryException

[O.B.]

I have an application that throws System.OutOfMemoryException when the
application has only allocated 1.3GB of RAM (according to the Task
Manager). I've repeated the operation several times and the exception
is thrown either when I'm calling Add or ContainsKey of a
System.Collections.Generic.Dictionary object with around 5.9 million
values (the size is different each time but around 5.9M each time).

The computer has 2 GB of physical RAM and runs Windows XP Pro. Virtual
memory is set to an initial 2GB with a maximum of 4GB of RAM. It is my
understanding that applications can have up to 2GB of addressable memory
in Windows XP Pro. What is going on here? Is this a limitation of the
Dictionary structure?

 

[Willy Denoyette [MVP]]

|I have an application that throws System.OutOfMemoryException when the
| application has only allocated 1.3GB of RAM (according to the Task
| Manager). I've repeated the operation several times and the exception
| is thrown either when I'm calling Add or ContainsKey of a
| System.Collections.Generic.Dictionary object with around 5.9 million
| values (the size is different each time but around 5.9M each time).
|
| The computer has 2 GB of physical RAM and runs Windows XP Pro. Virtual
| memory is set to an initial 2GB with a maximum of 4GB of RAM. It is my
| understanding that applications can have up to 2GB of addressable memory
| in Windows XP Pro. What is going on here? Is this a limitation of the
| Dictionary structure?

Your application can only address up to 2GB of memory, but this 2GB has to
be shared with the code, this means that you don't have 2GB to store data.
Note also that the underlying store of a Dictionary consists of two array's,
and arrays need contiguous storage. The way code modules are laid-out in
your address space restricts the largest size of contiguous memory to
something like 1.2 - 1.6 GB depending on the type of application. Note also
that you should initialize the dictionary to the size (in entries) you are
expecting (if at all possible), that way you prevent excessive fragmentation
and restrict the allocation of entries to what you effective need (well,
more or less , there is some % of free entries anyway). Note that it's
insane to allocate such huge containers and expect that you won't run out of
memory space when running on a 32 bit OS, you should change your design or
move to a 64 bit OS if this is not an option.

Willy.