- Home /
Which is better for performance, removing or disabling a component?
I am making a building game. i have a buildable gameobject, and when I instantiate it, I need access to a script that controls certain options. Once the object is finalised, these scripts are no longer needed. In this particular case, there could be ++thousands++ of these objects in the gameworld.
Will the performance overhead of continuously running these objects with the component disabled outweigh the performance cost of using remove component to get rid of them completely?
In theory, I would imagine that the best way to do it would be to remove the component, but would like some advise from anyone who may have some solid advice they can give.
It is possible to test this yourself using the profiler that Unity provides. You can just time both ways and see which is faster.
If you can't tell any difference in performance between the two methods, then it's not significant enough to worth worrying about and you should just go with the way that is easier for you.
It is a bit difficult to understand what you're trying to do since you don't give the specific example that you're concerned with.
Answer by Suddoha · Aug 29, 2015 at 12:09 AM
This all depends on how frequently you want to remove the components.
As it's a building game and the destruction of the component only happens every now and then when the user is finished tweaking the object, it wouldn't hurt at all.
If you had some kind of logic that destroyed components frequently, for example every frame or even several components per frame, you should think about an alternative.
You said there may be thousands of objects in theory, so If you simply disabled the components, you'd waste pretty much memory in the end, even though some platforms wouldn't bother at all. Keep it clean and easy.
This being said, i want to mention another way, maybe even a better approach:
Have a manager-like object that provides the script(s) with the functionality you need and as soon as you instantiate a new gameObject, register that one to the script. You'll ever need only one instance of the script, that simply takes the current object and offers your functionality.
Another advantage of that is, that you could store a list of favourite settings / presets that could be applied per button-click, but that depends on what you actually want to tweak. That would make sense if you had modular objects and allow options like changing the textures, colors, size, .... of course it wouldn't make that much sense for positioning. But that's up to you, be creative. ;)
Answer by Addyarb · Aug 27, 2015 at 11:01 PM
Could you post some code? I have a feeling you could vastly optimize your game by settings each object as a temporary variable and using a foreach loop to control the parameters of the scripts attached. That being said, there is a credible post here that you should check out if you really do need a script on thousands of objects at once.
Good luck!
Thanks for the advice, but I don't think I made myself totally clear. Code is not really needed, as this is a generic question. Let me try and phrase it in a better way.
When a game object is instantiated, it requires use of a script to control certain parameters. Once that is done, the script is no longer needed on the game object. Normally disabling the script would be ok, However, it may be that thousands of these game objects get instantiated over time. So they would all be sitting there with a disabled script that is never going to be used again.
As far as I am aware, disabling a component does not free up it's memory allowance, so while the act of disabling is cheaper than removing the component, over time, with many objects, is the better option to use the remove component?
Bearing in $$anonymous$$d, the removing or disabling of the component is only every done once per element, but upto a maximum of 25 elements could be spawned at once. That number will probably eventually move up to a maximum of around 169 potential element spawns at once.
As you can see, over the course of a very short time, this can build up to a huge number of objects with a redundant disabled script on them.
I hope I explained myself better there.
So what exactly are you trying to set on the GameObject?
If you're setting something like a transform's position or some other value of some pre-existing component that will always be used in the GameObject, you can just set those values in the same block of code that you instantiated it in.
I.e. where you instantiate the object:
GameObject someObject = Instantiate<GameObject>(/* something */);
someObject.GetComponent</* some component */>().setSomeValueToSomething(value); // Repeat this line as needed
There's no need for a script that only sets values, since you can just set values this way.
Answer by SoulRider · Aug 29, 2015 at 03:39 AM
Thanks for the answer, that is pretty much what I was looking for. Since originally posting this, I have decided to rewrite the structure, and tame some of my ideas, so that I may be able to get away without using a script on the object at all, but we'll see how that goes.
Thanks again.
Your answer
![](https://koobas.hobune.stream/wayback/20220612001712im_/https://answers.unity.com/themes/thub/images/avi.jpg)