Jump to content
  • Advertisement
Sign in to follow this  
Flimflam

[.net] Using 'new' in long running loops.

This topic is 3758 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi everyone, I've got a question for you guys. I've been wondering something about the .NET runtime. In tutorials, be it the old managed directx and even XNA I always see people doing things like: 'Rectangle rect = new Rectangle()' among other data types inside their render loops, to be hit every frame. My question is this: Is creating new instances of objects inside a long running loop something to avoid? I'm mainly confused about how garbage collection handles this. Does it cause GC to collect more frequently? Does it have any performance logic behind it? Should I always try when possible to allocate simple things outside the loop whenever possible? I'm thinking these tutorials/examples are doing it for simplicity sake, but it's also sending the wrong message. Any feedback would be appreciated :)

Share this post


Link to post
Share on other sites
Advertisement
The less allocation you do, the better. If you have objects that persist across frames, don't new them every frame.

The GC just runs whenever it runs. The more stuff there is to collect, the longer that process takes. So minimizing allocations is a sensible strategy for performance.

I know this is .Net, but in C++ and other "low level" languages we create special pools for frequently new'd objects. Basically it's a pre-allocated array of space for them, and when you new one of these special objects it actually just constructs them in that already allocated memory; when you delete them it just marks the memory as free. You get pretty astounding performance boosts from using such strategies. However, I don't know if such techniques are even possible in a managed language.

-me

Share this post


Link to post
Share on other sites
Thank you.

C++ and friends is the reason why I was so confused (done most of my programming in c/c++). Doing things like these allocations every frame in this way is not something that makes a lot of sense, but I see it all the time in .NET code so I started to wonder if there was a reason behind it. I suppose it was just for simplicity of explaining things.

Thanks again :)

Share this post


Link to post
Share on other sites
Quote:
Original post by Flimflam
I'm thinking these tutorials/examples are doing it for simplicity sake, but it's also sending the wrong message.


You're probably right that they're doing it for simplicity, in that they don't want to obfuscate the main point with peripheral issues, but the approach isn't necessarily "wrong."

Here is a good overview of the .NET garbage collection algorithm from MSDN.

A few of the important points to take away is that allocations under .NET are extremely fast because the runtime maintains its own internal memory pool that can be allocated from by essentially incrementing a pointer. No request to the OS needs to be made unless you fully consume all of the readily-available space. Additionally, objects such as the Rectangle in your example, will be a Generation-0, or "short lived" object, which are optimized for fast collection. Only if the object survives Gen-0 collection will it be promoted to a less frequent but more impactful stage of garbage collection.

This is not to say that code should allocate all over the place without a care, but individual allocations do not carry the weight that they do in unmanaged languages. If you conceptually need new objects each frame, don't be afraid to do so, unless profiling has specifically revealed GC time as a bottleneck.

Quote:
Original post by Palidine
However, I don't know if such techniques are even possible in a managed language.


They are, but because of the way the GC works, they're usually not necessary.
The article explicitly discourages doing manual object pooling, because the runtime is basically doing pooling for you already, and doing it manually can interfere with the collection algorithm.

As an aside, since you mentioned XNA, there are caveats to this. The GC of the runtime on the 360 is less sophisticated than the PC counterpart, and I believe is non-generational. In this case, collections are more impactful, but avoiding blatantly wasteful allocations such as large chains of operator overloads that return intermediate objects should help. In the extreme case, object pooling has been said to be a viable way to overcome the shortcomings of the GC on the 360 when dealing with pathologically numerous object creations like particle systems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Palidine
The GC just runs whenever it runs. The more stuff there is to collect, the longer that process takes. So minimizing allocations is a sensible strategy for performance.

I don't know much about .NET, but the above is not generally true of GCs. The amount of work they have to do tends to depend on the amount of live data, not on the amount of garbage, unless the garbage needs to be finalized. This is why increasing the size of heap improves GC performance, since it doesn't need to be invoked as often.

Generational GCs can indeed be quite quick to collect short lived objects, matching performance of stack allocation.

Share this post


Link to post
Share on other sites
You should keep in mind too that value type objects (structs) don't have any GC performance at all unless you box them. Rectangle in XNA is a struct, so it is stack allocated. Doing something like
Rectangle r = new Rectangle()

is just initializing r, the values from the new rectangle are copied over whatever memory was in r.

The same is not true for arrays. Rectangle[] is a reference type, so reallocating arrays adds memory pressure to the GC. Also casting structs to Object or an interface type causes them to be boxed, and allocated on the heap. So that is something to avoid if you want to reduce the pressure on the GC.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!