koobas.hobune.stream
Don't allocate memory in Update loops on iOS. - How strictly should this be followed?
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;
?
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 _newPos_ or _tintColor_ and I then know that them variable are simply here to avoid memory allocation and really do not hold anything relevant.
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.)
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?
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.
@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.
@Peter G: I know all that. I was just wondering why $$anonymous$$ 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).
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:
It is ok to allocate structs such as Vector3 in your functions. They won't add any memory consumption.
Don't allocate any classes such as Transform during a function.
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. ($$anonymous$$aybe I'm misunderstanding your post though.)
@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.
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?
@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
