views:

477

answers:

4

hi!

so in c++ it's very easy. you want whatever class/struct to be allocated on the heap, use new. if you want it on the stack, don't use new.

in C# we always use the new keyword, and depending on whether it's a struct or a class it's allocated either on the stack or on the heap (structs go to the stack, classes to the heap) - and in some applications there can be a HUGE performance difference when changing the design such that only those objects go to the heap that really belong there.

What I wonder is - is there a direct way to control where an object is allocated independant of whether it's declared as struct or class? i know that value types (structs) can be boxed to go to the heap (but boxing/unboxing comes at a performance cost). is there a way to allocate classes on the stack?

Also, is there any mechanism to allocate raw memory and use something like placement new in C++? I know that this breaks with the idea of being managed - but it can make a big performance difference if you can use your custom memory management.

I love C# for it's convenience, for it's garbage collector and other things - but sometimes, when working on the bottleneck of an application, it meight be desirable to have more control over what is actually happening.

Any tips/hints welcome :)

edit: performance example:

struct Foo1
{
    public int i;
    public float f;
    public double d;
}

struct Foo2
{
   public Foo1[] bar;

   public void Init(){
        bar = new Foo1[100];
        for (int i = 0; i < 100; i++)
            bar[i] = new Foo1();
    }
}

class Program
{
    static void Main(string[] args)
    {
        DateTime time = DateTime.Now;
        Foo2[] arr = new Foo2[1000000];
        for (int i = 0; i < 1000000; i++)
        {
            arr[i] = new Foo2();
            arr[i].Init();
        }

        Console.WriteLine((DateTime.Now - time).TotalMilliseconds);
    }
}

This takes 1.8 seconds on my machine to execute (note that there is actually only allocation going on - no parameter passing)

if Foo1 is changed from struct to class, execution takes 8.9 seconds! that's five times slower

+2  A: 

Your explanation of where value types vs. reference types go (stack v. heap) is not completely correct.

Structs can also get allocated on the heap if they are members of a reference type for example. Or if you have boxed them while passing them via an object reference.

You should read http://www.yoda.arachsys.com/csharp/memory.html to get a better understanding of where different types actually are allocated.

On a separate note, in .Net, you really shouldn't care about where a types is allocated - as Eric Lippert writes: the stack is an implementation detail. You are better off understanding the semantics of how types are passed (by value, be reference, etc).

Furthermore, you seem to be making an implication that allocating an object on the heap is more expensive than on the stack. In reality, I would argue that the performance cost of copying value types outweighs the benefit of any savings in a slightly quicker allocation on the stack. The biggest difference between stack and heap, is that on most CPU architectures the stack is more likely to be retained in CPU cache - and thereby avoid cache misses.

This is not the most important issue to be concerned with. You should decide whether the type should have pass-by-value semantics or not. If it doesn't - then perhaps it should be a reference type.

LBushkin
let's say you create a large array of some objecttype. The Array itself will go to the heap anyway. however - after my understanding - if the objecttype is a struct, the whole thing will be allocated in continguous memory (one cluster of data - or probably a few splitup depending on implementation) on the heap. however - if it's a class, each element of the array itself will be allocated on the heap as well - taking more time for allocation and making garbage collection slower
Mat
@Mat: the fact that array is allocated on the heap is an implementation detail. The fact that it is an array of references (i.e. pointers, for us C++ guys) is not, however.
Pavel Minaev
@Pavel - exactly that's what i mean (i don't care whether the array itself is on the heap, since a single allocation on the heap doesn't hurt as much as one allocation for each element) - so i think it's desirable to decide the referencetype/valuetype behaviour upon usage, and not upon declaration of the class/struct
Mat
A: 

While in the general case it's true that objects are always allocated on the heap, C# does let you drop down to the pointer level for heavy interop or for very high performance critical code.

In unsafe blocks, you can use stackalloc to allocate objects on the stack and use them as pointers.

To quote their example:

// cs_keyword_stackalloc.cs
// compile with: /unsafe
using System; 

class Test
{
   public static unsafe void Main() 
   {
      int* fib = stackalloc int[100];
      int* p = fib;
      *p++ = *p++ = 1;
      for (int i=2; i<100; ++i, ++p)
         *p = p[-1] + p[-2];
      for (int i=0; i<10; ++i)
         Console.WriteLine (fib[i]);
   }
}

Note however that you don't need to declare an entire method unsafe, you can just use an unsafe {...} block for it.

Blindy
what I was looking for =) thanks!
Mat
Note that this requires some special permissions, so if you run your code in less than a full trust environment, you may run into trouble. An example of this is Silverlight.
Blindy
Did you mean "in the general case it's true that objects are always allocated on the *heap*"?
gWiz
As a side note, the reason why there is no way to do it "the other way around" - a kind of a "placement `new`" for C# classes - is because classes have to be tracked by GC, as well as everything they reference, and that isn't possible to implement (efficiently, anyway) with just any random memory block. So with classes, you're stuck with the heap. Also, the trick described in this answer won't work for structs which have fields of reference types (again, because GC must be able trace them). Fields of pointer types are fine, though, so it's just as expressive as plain ANSI C.
Pavel Minaev
why do they have to be traced by the GC? if i allocate something on the stack, i'm fine with it being deallocated once it goes out of scope - or if it's used in an array, and therefore the objects are allocated continguously in memory, then i'm fine with the objects being deleted as soon as the array is deleted
Mat
@Blindy: how would one - using this unsafe syntax - define an array variable of CLASS Foo: - Foo[] myArr; - such that it would be equivalent to following C++ syntax: Foo* myArr = new Foo[100]? (as oposed to Foo** myArr = new Foo*[100], which is what C# does by default)
Mat
The best you can do is `Foo *myArr=stackalloc Foo[100];`
Blindy
The reason why it has to be GC-traced is because .NET guarantees memory safety, which, among other things, means "no dangling references". In C++, if you create an object on the stack, get a pointer to it, store it past the lifetime of the object, and then use it - well, it's U.B., but the runtime won't stop you. .NET is specifically designed to avoid such things. Hence it _must_ trace references to ensure that object is unreferenced prior to deallocating it (as an optimization, if it can statically prove that object isn't referenced - escape analysis - it can skip the GC and use the stack).
Pavel Minaev
stakalloc is best left as a JIT optimization.
Henk Holterman
+1  A: 

Dont worry about it - you head is still in the c / c++ world where it can matter a lot where things go. There are a bunch of really smart people in CLR team who spend all day worrying about making this magically fast.

There are some gotchas in c# and memory usage usually assocaited with creating lots of tiny object by accidents (doing string = string + other string in a loop is a classic)

There is a memprofiler that will show you whats happening if you really think you have a perf issue caused by memory management

I have written lots of performance intense code (graphics rendering clients, network servers) in c# and never had to worry about any of this

pm100
but especially in graphics rendering, this meight make a big difference. for example a particle system will be a lot slower if each particle (even when stored in an array and reused upon death) is allocated on it's own on the heap as opposed of being allocated in one bunch of memory
Mat
make a big array of particle structs (as other posters pointed out , you can put structs all over the place, not just the stack). You will end up with one big contigous block of memory
pm100
exactly - but the point is, that this decision has to be taken when the code for the particle is written. if you want to use some class from a library, you don't have the choice of allocating it in one continguous block
Mat
+1  A: 

This is the wrong way to view structs and classes in C#. In C# the difference between a struct and a class is not where it is allocated, but the copy semantics. A struct has value semantics and a class has reference semantics. C++ programmers tend to read more into this, as they are used to objects on the stack having value semantics and objects on the heap having reference semantics.

How this memory is allocated is an implementation detail of the runtime. The runtime can use stacks, heaps, or any other hybrid allocation scheme it likes. While it's true that usually structs will be allocated on something like a stack, and classes will be allocated on some sort of a heap, it is not required. For example, a class allocated in a function and not passed outside the scope of the function could quite easily be allocated on the stack instead.

Niall
i do have quite good control over the copy semantics independantly of whether it's a struct or class. i can use deepCopy/shallowCopy to have copying for reference types, i can use boxing/unboxing to get reference semantics for valuetype, i can use ref keyword to accept value types by reference as a function parameter. But deciding about where to allocate a variable can be important for performance too
Mat
I'm not saying that choosing between a class and struct is the one and only way to control copy semantics. I'm saying that class/struct is only about copy semantics, not about allocation policy. You might change the performance against a particular runtime by persuading it to allocate differently, but that is implementation dependent. Which is fine if you're optimizing for performance. The cases where this will actually make a difference are probably rarer than you think though.
Niall
but that was my question - my problem is that i've got the tools for persuading copy semantics, but i don't have the tools for persuading allocation behaviour. And that class/struct is not about allocation policy is not true - for example read this msdn article: http://msdn.microsoft.com/en-us/library/aa288471(VS.71).aspx "When you call the New operator on a class, it will be allocated on the heap. However, when you instantiate a struct, it gets created on the stack. This will yield performance gains."
Mat