Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

ShlomiSteinberg

new and delete operators

This topic is 5548 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

Advertisement
ahhhh... dont.. never.. even think about that... if you know that you need thost 500 floats all the time, then why on earth would you want to allocate and free the memory 30-60 times per second? even if it was fast it would be a complete waste of precious cycles

in short: no, they are not and usually you should avoid allocating/freeing memory at runtime

Share this post


Link to post
Share on other sites
Allocating memory each frame???Are you nuts???

The PAIN is coming...this summer!!!In cinemas everywhere.

Share this post


Link to post
Share on other sites
Although what each of the above posts says is essentially correct (allocating mem every frame is a bad idea) the chances are that you would not get much impact, if any.

Share this post


Link to post
Share on other sites
Use dynamic memory allocation *VERY* carefully. There is cases where you dont have choices...if you go with a oop approch then you will often face situations when you need to create a new object with the new operator...but try to make it so that there is as few possible memory allocation during run time.

Share this post


Link to post
Share on other sites
What''s wrong with dynamic memory allocation??? Does anyone have specific performance-impact information, or is this thread just mostly wind?

It is a GOOD thing, just use it wisely (like everything else!). I understand (and agree) you want to minimize the amount of code that is run every single frame, but why are some of you saying to avoid allocation at runtime in general? Why???? You want to hardcode all your array lengths? You know how many items the user wants/needs and how many files they will use?

You should NOT avoid dynamic mem allocation, you SHOULD use it.

Share this post


Link to post
Share on other sites
quote:
Original post by BriTeg
What''s wrong with dynamic memory allocation??? Does anyone have specific performance-impact information, or is this thread just mostly wind?


i think with nearly all sources for game development telling you not to allocate/free memory at runtime if you dont have to its more or less common knowledge. i havent profiled it as such, but i can tell you that a list will be a lot slower than an array if you add and remove items a lot. so instead of creating and deleting hundreds of items its definitely faster to sacrifice the memory and keep an array of a maximum size. though yes, that would be completely pointless if its for savegames in a load/save dialog or other not so critical sections.

quote:

You should NOT avoid dynamic mem allocation, you SHOULD use it.


sooner or later everybody will come to the point where he wonders if its better to have a list of bullets or an array for 1000 bullets with just a fraction of them active most of the time.

Share this post


Link to post
Share on other sites
Its not so much running new/delete at runtime thats the problem, its running said operations dueing the main game loop which can be an issue.

Its not so much a speed thing (althought that is important) but constantly calling new and delete can lead to memory fragmentation which over the lifetime of the gameloop can start slowing up new/delete calls as the OS heap manager has to do more work to grab your requested memory.

Also, as was mentioned, if your making and deleting 500 floats a frame why not make once and leave until end of game/lvl change and then clean up? Saves alot of cycle waste that way which could be better used for other things.

Finaly, I belive its Game Programming Gems 1 which gives a nice tip of handling new/deletes yourself via your own internal heap (in fact, i belive all 3 books in the series have articals on memory allocation and how to avoid expensive new/delete calls to the OS) so that you grab a large chunk of memory and allocate from that via pointers, this is nice and fast AND lets you avoid memory fragmentation.
Also, for stuff like particals its often better to have an alive/dead list so that you dont have to keep new/deleting stuff for them (this also has a side benifit that you can limit the amount of particals on a system via the setup to stop the partical system killing the machine)

I feel i''ve waffled enuff

Share this post


Link to post
Share on other sites
Again, I agree that minimizing your main game loop is a Good Thing. Of course having a permanent array of 500 floats is better than allocating and freeing them every single frame. And allocating large chunks less often can be better (but a little more complicated) than allocating small chunks more often. But people see "avoid dynamic allocation" and think it means *all* the time, that new and delete are some sort of evil feature. They''re just tools, like everything else, and you should use your tools properly. Overall general design of your main game loop is WAY WAY WAY more important than using a permanent array instead of new/delete.

For a simple test, I took NeHe''s lesson 7 (the rotating texture mapped cube), and added code to allocate and then free (using new/delete) an array of 500 floats right before calling DrawGLScene(). Yes, there was a performance hit, but it was surprisingly small: 0.2% of the total CPU usage. Roughly about the same as the call to PeekMessage which is called every frame as well. And I did not notice any drop in frame rate. In fact, I had add a loop to allocate and free the array *80 times every frame* before the CPU usage of the alloc/free stuff matched that of the DrawGLScene function (which simply draws a single texture mapped cube). And even here, overall FPS wasn''t really affected. And this was in debug mode, with all the overhead that adds - doing the same test in release mode, I had to alloc/free the array *500 times* every frame before it matched a single call to DrawGLScene()!

Now, I realize these numbers will vary from machine to machine, but it should help illustrate that use of new and delete are not performance killers. If you can optimize them away, of course go ahead - but if your main game loop is taking too much time, your main culprit is your overall design, not a few extra calls to new/delete.

Brian

Share this post


Link to post
Share on other sites

  • 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!