|
I read in the manual that its best to avoid memory allocations in Update functions. I understand what this means generally, don't create new textures every update, don't instantiate objects every update. But I wonder how intensely must you adhere to this? Like for example I tend to do alot of Vector3 newPos = transform.position; newPos.y += Time.deltaTime; transform.position = newPos Should I not be doing something like that in update? Should I make like a temporary 'globalUtilityVector3' outside of the update loop, so then I don't have to create any temporary Vector3's to read in and out data? I also do alot of GUI.TintColor = new Color(1,1,1,.5); should I not do that either? Should I declare a 'globalUtilityColor' outside of Update and then go globalUtilityColor.a = .5; GUI.TinColor = globalUtilityColor; ?
(comments are locked)
|
|
Hi, You could/should store newPos , Color infos, etc in variables yes, and that would avoid creating it on each update. I don't know what kind of standard you should follow to write them but I use something like EDIT: It seems that this is not important after all given all the comments, but without a proper bold statement from Unity in their docs ( haven't find one, but willing to learn!), I still prefer avoiding creating new variables inside function, when the function is called a lot during your game loop most likely). It might be unnecessary, yes, but I feel better like that with my current experience. Bye, Jean Are you saying that with iOS it's important even to avoid creating objects that would typically be stack-allocated? (Just curious.)
May 16 '11 at 02:47 PM
Jesse Anders
I was watching the memory on the iPad and the growth of memory allocation was well within the garbage collectors control. So technically you probably don't need to worry about it. BUT I am personally kind of obsessive with such things. I mean doesn't it take the gargbage collector extra cycles to cull things from memory? So if you can avoid the garbage collector wouldn't you get better performance, even if its small?
May 22 '11 at 09:36 PM
eem
I think eem is right. It's the sort of thing that if you have it on every enemy in your game, that little bit could multiply out to big savings if you have a ton of enemies.
May 22 '11 at 09:59 PM
UltimateBrent
@Jesse Anders, Unity actually encourages that you use Stack Allocated objects simply because they don't increase the total memory allocation. So you can use them all you want.
May 22 '11 at 11:48 PM
Peter G
@Peter G: I know all that. I was just wondering why Jean was suggesting that creation of stack-allocated objects should be avoided (which doesn't seem to make much sense, for the very reasons you've mentioned).
May 23 '11 at 02:57 AM
Jesse Anders
(comments are locked)
|
|
Actually, the Vector3 and globalUtilityColor won't do anything to your memory allocation. Since they are stack allocated, you will see zero memory allocation from them. Rule of thumb:
I would say if you are debating creating a struct locally, DO IT. It will give you cleaner code. Looking at a long list of global variables that are only used inside of one specific function will confuse anyone who looks at your code. Actually, a statement such as 'newPos = transform.position' shouldn't allocate any (non-stack-allocated) memory, I don't think. No new object is created; all that happens is that a reference to an existing object is returned. (Maybe I'm misunderstanding your post though.)
May 23 '11 at 02:55 AM
Jesse Anders
@Jesse Anders, thanks for catching that. I don't know why but I had always thought that Component looks up allocated memory. I just tested it and you were correct. Thanks.
May 23 '11 at 05:46 PM
Peter G
What about newPos = new Transform()? That will allocate memory won't it? Is there a list somewhere that would tell me what things go on the stack vs the heap? Do Rects go on the stack? And why doesn't the stack increase memory allocation? Does C# go through your entire app and figure out how much memory the stack could expand to and allocate that before hand or something like that?
May 24 '11 at 09:45 AM
eem
@eem, yes you would never create a Transform by directly calling the constructor, but in theory that would allocate memory on the heap. If it is a struct/value type, then it is put on the stack. Reference types and classes go on the heap. With the stack allocation, among a number of other things, functions can put values on top of the stack, but they are responsible for removing it when the function returns so the final change will be zero. This page is kind of a stub, but the bottom links to some other similar concepts. http://en.wikipedia.org/wiki/Stack-based_memory_allocation
May 24 '11 at 07:25 PM
Peter G
(comments are locked)
|
