Search Unity

  1. Unity 2019.1 is now released.
    Dismiss Notice

Management of many independent Objects with the same Script [Performance]

Discussion in 'Scripting' started by NekoPAK, May 25, 2019.

  1. NekoPAK

    NekoPAK

    Joined:
    Apr 17, 2019
    Posts:
    3
    Hi!

    I am working on a game/interactive installation similiar to Game of Life and before I pass the Prototype stage I have several questions to best practices regarding management of many independent Objects with the same Script regarding performance. There will be hundreds of game objects and small actors which will have access to the same script (but different values of course) and they will interact with each other, based on specific rules and "ingame physics". It's gonna be very script heavy, since the graphics will be 2D and very simple.

    Are there any leads to memory management? Or to batch the computations done by the actors? I know that optimization comes at the end, but I'm afraid that, if I start wrong it will be super hard to refactor the code base, so now I'm looking for ways to have the best possible start and base system
     
  2. csofranz

    csofranz

    Joined:
    Apr 29, 2017
    Posts:
    489
    This appears to essentiall be the same question as this.

    It boils down to the question: how much is 'many' - when will the number of independent objects and the performance cost for the dispactch algorithm become a performance factor?

    The answer (IMHO) is: the performance gain you can squeeze out of invocation optimization pales in comparion with nearly everything else. There is a minute optimization potential, but likely, you'll get much more out of other optimizations, as identified by the profiler.

    Just make sure you comply with this, and you should be fine for the most part.
     
  3. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    4,567
    You can create list, or array of objects, having major system to control them all, by iterating through them. You can filter as we active and inactive objects.

    That is one option of many.
     
  4. NekoPAK

    NekoPAK

    Joined:
    Apr 17, 2019
    Posts:
    3

    Regarding the number of objects, laying it out in theory the installation could have between Hundreds to Thousands of active game objects - not all of them are active all the time and interacting all the time, but most of the time they do.

    Thank you for the links - i guess the things referred by your statement "nearly everything else" can be found in the links or are referred to general programming stuff (like caching variables, loops, and so forth?)


    @Antypodish
    Thanks for the idea - is this prefarable to let the objects do their own stuff in the Updateloop? I have a manager but so far, the manger does not do much except for indexing/keeping track of the objects and their uses.
     
  5. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    9,320
    If you're asking about performance for this type of scenario, look into the Entity Component System (ECS). (See also this blog post.)

    If you're just getting started with programming, or if performance doesn't really matter in the big picture, the answers above will support a simpler, more traditional approach.
     
  6. NekoPAK

    NekoPAK

    Joined:
    Apr 17, 2019
    Posts:
    3
    I've been progamming in Unity using the traditional approach with components (so I'm not getting started with programming, and with my other projects there were no major performance issues or optimizations needed), but that adresses the issues I am expecting of my installation, thank you very much!
    Is it compatible with Scriptable Objects? Or do I need them if I use the DOTS approach?
     
    Last edited: May 26, 2019
  7. Antypodish

    Antypodish

    Joined:
    Apr 29, 2014
    Posts:
    4,567
    ECS is parts of DOTS. But you can consider using only jobs. At least as part of learning and preparing for ECS.

    Some people did manage make SO working with ECS, if that what you are asking. That was while ago, when I read about this solution however.
     
  8. TonyLi

    TonyLi

    Joined:
    Apr 10, 2012
    Posts:
    9,320
    You probably don't want to use ScriptableObjects because they break the memory linearity that ECS benefits from. And since they inherit from UnityEngine.Object they inherit a lot of baggage that will needlessly fill up your cache.

    Given what you describe, I'm not sure that you'll need ScriptableObjects anyway. ScriptableObject assets, on the other hand, are still useful for holding design time data. At runtime, you'll want to load their data into simple ints, floats, and/or structs.