'Performance cost of 'new' in C#?
In C# what is the performance cost of using the new keyword? I ask specifically in relation to games development, I know in C++ it is a definite no-no to be newing things every update cycle. Does the same apply to C#? I'm using XNA and developing for mobile. Just asking as an optimization question really.
Solution 1:[1]
There are three parts to the cost of new:
- Allocating the memory (may not be required if it's a value type)
- Running the constructor (depending on what you're doing)
- Garbage collection cost (again, this may not apply if it's a value type, depending on context)
It's hard to use C# idiomatically without ever creating any new objects in your main code... although I dare say it's feasible by reusing objects as heavily as possible. Try to get hold of some real devices, and see how your game performs.
I'd certainly agree that micro-optimization like this is usually to be avoided in programming, but it's more likely to be appropriate for game loops than elsewhere - as obviously games are very sensitive to even small pauses. It can be quite hard to judge the cost of using more objects though, as it's spread out over time due to GC costs.
The allocator and garbage collector is pretty good in .NET, although it's likely to be simpler on a device (Windows Phone 7, I assume)? In particular, I'm not sure whether the Compact Framework CLR (which is the one WP7 uses) has a generational GC.
Solution 2:[2]
Allocation in C# is actually faster than in C++. It just involves increasing the heap pointer and returning that pointer. Generally, objects get newed up more often in C# than in C++, as there is a bit more immutability involved in things like strings.
As others have pointed out, the real beast is the garbage collector, which is a bit tricky to profile. Nonetheless, even GCing is in most cases just as fast if not faster than delete in C++ -- just that you can't predict when it'll happen.
Some hints by Rico Mariani, the perf guy on the .NET team: http://msdn.microsoft.com/en-us/library/ms973837.aspx
It's a bit old and there have been a few improvements on the GC, but most of the information is still relevant.
I should add though that the XNA/Compact Framework Garbage Collector is somewhat slower than in the x86 version to trade off CPU for memory performance, so you should beware of that.
EDIT
I forgot to mention, and this is important: value types, including structs, use the new syntax too, but they're created on the stack rather than on the heap, so there's no GC cost for those unless you box them.
Solution 3:[3]
The cost of the new operator itself is negligible. What might cost is the processing that happens in a custom constructor. So if you have lots of things going on in this constructor it could be a problem.
Solution 4:[4]
You should always code the "easiest" way then measure bottlenecks, if they are present.
Anyway, I'd never code games in C# .
EDIT
Since it caused resentment, I mean that I'd never code in C# if C++ was an option available. This is what I thought since the OP also tagged C++.
Solution 5:[5]
The cost of new itself is most likely not significant, but as allocating new objects on the heap (when creating instances of reference types) may trigger a garbage collection, the side effect may be significant in a game. If you're worried about GC you can either use value types or reuse objects.
Also, as Darin correctly points out, the constructor may do a lot of work.
Solution 6:[6]
There is almost no cost associated with new operator in c# but when you use new on reference type , a heap allocation will be there and this is maintained by GC. If the memory is contineous than allocating memory is just a pointer movement but if the GAP between two allocations are found than GC will consult a free list of avaliable memory (a link list) to find the required object this will some time requiries o(n) travelsal time.
Solution 7:[7]
In C# the memory is kept defragmented by the Garbage Collector, so finding and allocating memory is a very fast operations. However the occasional defragmentation performed by GC can slow down considerably
Solution 8:[8]
When you write new in c# the CLR allocates memory to the object on managed heap.
Please look at the below link for more on this :
http://msdn.microsoft.com/en-us/library/ee787088(v=vs.100).aspx
Since the garbage collection is automatic in C# (only case when during testing people use GC.Collect to manually trigger it) , game design on c# is a bad idea.
You should look for C++ for the purpose as there you have destructors.
~ClassName()
{
//kill my object and reclaim memory.
}
Solution 9:[9]
Normally, it's a performance black hole for c# to miss the stack allocation for micro structure like Rect, Point and all others. Space allocation on the stack is just bp:sp = bp:sp + size for the cpu, while heap allocation with New require many algorithm, gc control, large memory page size, eventualy on disk, relocation, etc
Solution 10:[10]
My measurement shows, a "new" to reference type can sometimes take as long as 2.2 seconds and can sometimes be as fast as a few ticks. Bottom line is that there is no real-time guarantee in .net GC and performance can vary significantly in random manner. So I'd suggest for real-time designs, e.g. gaming, don't call "new" to reference types in the real-time part of your code (e.g. update loops), for there is no real-time guarantee.
Of course, many people will argue that how often a "new" would take 2.2 seconds and does it matter if happens only once of several hours. Well this has to be the judgement of the designer. But for the sake of academic arguments, GC is not real-time, hence don't call "new" in real-time codes.
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow