unmanaged memory and large object heap

[cronusf]

We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

 

[Jochen Kalmbach [MVP]]

Hi cronusf!

We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Jochen Kalmbach [MVP]]

Hi cronusf!

We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

 

[Ben Voigt [C++ MVP]]

We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

Like the article points out, the problem is created by large objects that
grow frequently. Allocate some extra space so you don't have to grow as
often and you shouldn't have any problem. Most dynamic array containers
(std::vector, System::Collections::Generic::List, etc) grow on power-of-2
boundaries, which helps with both performance (less copying the data to a
new location) and reduces fragmentation (free blocks are of commonly used
sizes).

Or use a linked list and stay off of the LOH, if you don't need random
access. Or a hash structure, like System::Collections::Generic:ictionary
if you need random access but not ordering.

 

[Ben Voigt [C++ MVP]]

We allocate some large temporary arrays, and this is causing problems
for us with the way the large object heap is managed (http://
www.simple-talk.com/dotnet/.net-framework/the-dangers-of-the-large-object-heap/).

We mix C# and C++\CLI assemblies. I can move the large array
allocation to the C++ level, and I was wondering, if I use native
arrays instead of managed arrays, will my problem with the large
object heap go away?

Like the article points out, the problem is created by large objects that
grow frequently. Allocate some extra space so you don't have to grow as
often and you shouldn't have any problem. Most dynamic array containers
(std::vector, System::Collections::Generic::List, etc) grow on power-of-2
boundaries, which helps with both performance (less copying the data to a
new location) and reduces fragmentation (free blocks are of commonly used
sizes).

Or use a linked list and stay off of the LOH, if you don't need random
access. Or a hash structure, like System::Collections::Generic:ictionary
if you need random access but not ordering.

 

[cronusf]

Hi cronusf!



The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.

 

[cronusf]

Hi cronusf!



The problem will be te same... it will be even worser...
Exept if you create your own allocator (and do not use the CRT/OS).

Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.

 

[Jochen Kalmbach [MVP]]

Hi cronusf!

Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.

The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

Greetings
Jochen

 

[Jochen Kalmbach [MVP]]

Hi cronusf!

Why will it be worse? If I use unmanaged arrays, it won't go on the
large object heap, right? It won't go on any managed heap, so it will
be as if I did it in native C++.

The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

Greetings
Jochen

 

[Ben Voigt [C++ MVP]]

Hi cronusf!


The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

I thought that compaction in the LOH means the same as in Win32 API heaps --
coalescing adjacent free blocks, never moving data.

But definitely yes, the native heap is just as subject to fragmentation as
the LOH.

 

[Ben Voigt [C++ MVP]]

Hi cronusf!


The LOH has a change to compact it and free some memory, if this is
possible. This is not the case in native heaps.

I thought that compaction in the LOH means the same as in Win32 API heaps --
coalescing adjacent free blocks, never moving data.

But definitely yes, the native heap is just as subject to fragmentation as
the LOH.