c# structs/classes stack/heap control?_问答_开发者

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 performanc开发者_运维知识库e 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

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.

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.

Don't be fooled by the new keyword, it's optional for structs.

In C# there is a managed world where you enjoy the Garbage collector and Type-Safety and don't (have to) worry about many memory details. The Stack/Heap difference is irrelevant, it's about copy-semantics.

For those rare cases where you do want control, there is the unsafe (unmanaged) part of C# with real pointers and everything.

But the cost of things are different in C# than they are in C++ so don't hunt ghosts, unmanaged, short lived objects are very cheap. And the compiler can allocate small arrays on the stack as an optimization, you won't be able to tell and neither should you care.

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

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.