Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

update() manager, less update() calls

Discussion in 'Scripting' started by luniac, Feb 11, 2016.

  1. luniac

    luniac

    Joined:
    Jan 12, 2011
    Posts:
    614
    So i read this blog post:
    http://blogs.unity3d.com/2015/12/23/1k-update-calls/#comment-311656

    I've written a reply:
    Hey i don’t understand this managed update concept.

    If i have 50 gameobjects with a script component that has update() function and inside the update it accesses gameobject position for example.

    In this case the gameobject position is unique to each gameobject.

    I need to have 50 update() calls, 1 for each gameobject.

    How do I implement an approach where i have only 1 update() in some manager and can access gameobject position of all objects??? i don’t understand how i would do this properly? Would i have to keep all 50 gameobjects in an array and access their positions in a loop and then pass data back into the gameobject?

    Is this better than having 50 update() funtions?
    seems like im just moving calculations from 50 script instances into 1 script instance but also increasing calls between scripts.


    Can someone make a tutorial or something showing how this works in practice?
     
    cdr9042 likes this.
  2. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Just use the usual unity 'Update' function.

    And if your script doesn't have an 'Update', don't put an 'Update' function in it.

    That blog post is getting into some design ideas that your higher level programmers would find more comfortable because the 'magic' aspect of unity reflecting out your update method to determine if it needs to be updated just feels dirty to some programmers. And yeah, technically you can eek out a little extra oomph from the system if you went with there single update manager.

    The thing is you lose a lot as well... they leave out, or only tangentially touch on, the fact that the update method in each script takes ever so slightly longer to be called because unity has a lot of protective code around that update call allowing for easier debugging, profiling, and the sort.

    If you don't understand what they're doing in that blog, you're just going to shoot yourself in the foot. Go with what is supported and documented by unity. Premature optimization like this is just a bad idea. There are much better places to optimize your game then this if you're truly having framerate issues.
     
    Ryiah and Kiwasi like this.
  3. luniac

    luniac

    Joined:
    Jan 12, 2011
    Posts:
    614
    Premature optimization is the first thing that popped into my mind.
    cool.
     
  4. luniac

    luniac

    Joined:
    Jan 12, 2011
    Posts:
    614
  5. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Yeah, isn't that just the same blog post luniac posted in the first place?
     
  6. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    1,188
    Sorry, my mistake, totally didn't see your link somehow. But yea if you already read that one, there's nothing more but saying most of it would be premature optimization.
     
  7. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    Yes. And that's whooping 200 bytes!!! (+array overhead like 8 bytes maybe? Most likely more)
    No. It's same (+- several nanosec you won't notice). On object count larger than 10000 I'd think. But Unity won't handle that much anyway in other places like rendering or physics.
    It won't help you at all.

    Last time I tried rendering 10000 objects that don't do anything(no Update() calls or whatever), I got horrible 20 FPS... So you would need to rearchitecture solution anyway.

    P.S. I forgot to mention profiling features: each method call comes with profiling overhead(especially in deep profile like on screenshots in article) so you're seeing overheads in profiler that aren't happening in real life with non-debug version.
     
    Last edited: Feb 11, 2016
  8. luniac

    luniac

    Joined:
    Jan 12, 2011
    Posts:
    614
    lol unity can't handle 10k objects that don't do anything?

    dammmm
     
  9. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Having 10,000 scripts with an update call doesn't mean you'd have 10,000 renderers.
     
  10. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    You want 10000 audio sources? Or 10000 of what exactly that requires them to be Unity based then? It's either physics or rendering or bones(+IK targets for bones or any other Transform uses like guiding something) - there's no other reason for them to be GameObjects which clutter Editor object list. Not only editor's object list will stutter, but also you will have a lot of unnecessary Transform allocations where they're not used.

    If every one of them is rendering in camera view at same time (none are culled) it will drop FPS considerably. Especially on mobile systems/intel GPUs or old PCs. Even camera culling requires operations and on mobile systems you want to reduce that as much as possible. Also don't forget it tries to dynamically batch, which requires quite a bit of resources. But having 10k active objects at same time means you have game architecture problems already.
     
    Last edited: Feb 11, 2016
  11. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    So what if it clutters the editor object list? The editor object list won't exist in final build.

    I'm not saying that I necessarily want 10,000, I'm just saying that just because there are 10,000, doesn't mean they're all renderers.

    What do you mean there's no other reasons for them to be GameObjects? We use GameObjects for all sorts of things. No problems whatsoever.

    gameobject_count_example.png

    Here alone you could see we use gameobjects to create an AI tree. That's just for one entity. No problems.

    Note for all those gameobjects seen in that list. There's 1 renderer, and no audiosource.
     
    Ryiah likes this.
  12. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,824
    I'm a bit confused by your replies. Your response kind of implies that you need a gameobject per script.

    A complex player, NPC or other kind of complex system designed with Unity's usual component based approach in mind may have lots of scripts, if you properly or even extremely take care of single responsibility principles, then it's not unlikely that you'll be having even more.

    That alone may lead to thousands of script instances with only a tenth or less GOs, many of them don't even need to be visible because they're position references, manager, and all that stuff that you usually don't see. So you can't just put this discussion aside like "it may have influence, but you won't be able to have that amount of GOs anyway so just don't care about it". That's at least what it sounded like.
     
  13. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    You can have 10 scripts per GameObject, it's still thousands of times less than what'll be noticable. Only difference between calling methods yourself and calling Update() from Unity's code is some checks as stated in blog link, so change won't be noticable before millions of calls per frame anyway - and that much calls require different solution anyway. OP is talking 50. What is 50 against millions?

    Because there's not 10.000 objects in list so Editor won't be slow. Besides, they don't have anything but Transform and don't have any scripts that receive Update() calls. So why would anything be different? Also, I've mentioned half of that use-case:
    So what are you showing? Behaviours packed into GameObject tree? I've seen better solutions and that's still not 10.000 GameObjects.
     
    Last edited: Feb 12, 2016
  14. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    How do you know what's on any of the gameobjects?

    There's all sorts of things from Rigidbodies, to Colliders, to custom scripts of mine...

    Which honestly was my point. That Renderers aren't the only thing that might be on GameObjects.

    And the thing is we could have MANY of these in our scene. This is a single brain. I've put 20 of them in the scene, wandering around, reacting to their stats. Hardly any slow down.

    And yes, many of the scripts do have Update calls, because they need them to track stats.

    I can't show ALL the scripts because that'd require too many screencaps (or a video), so here's just one of them. Note the scroll bar... my 2560x1600 screen isn't even tall enough to show all the scripts on them.

    gameobject_count_example_03.png
     
    Ryiah likes this.
  15. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    You don't read, do you?

    As I said...
    Update() call itself takes almost nothing. What are you trying to say?

    Because I'm saying you will run into other issues first (like rendering or physics, in this context), and Update() performance only with really, really bad architecture.

    P.S. Duplicating behaviour tree for each NPC is inefficient in itself, so it kinda proves my point further?
     
  16. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    Lol, I love that you cut off the 3rd part of those comma separated things... custom scripts.

    As well as the picture I posted containing no physics things.

    What I'm trying to say is that you claimed 10,000 GameObjects in a scene would slow the game to 20fps or less, because of all those renderers. And I refute this by saying you might have many gameobjects with out renderers.

    I agree, that's why my original post said to ignore the blog in general, as if optimization issues become an issue. There's better places to look than if you uses 'Update' vs and 'single Update Manager'.

    This proves your point that renderers are slow? I don't see how that proves your point.

    And it isn't inefficient... they work just fine, no slow down.

    Not sure how duplicating the behavoiur tree is that inefficient if each behaviour tree is stateful and has its own uniqueness.

    Or are you going to figure out from just a few screen shots how inefficient my game is... despite the framerate constantly being shown in the several hundreds. ???

    Here's the nice thing about my BT design... I can have unique BT's per entity. Or share BT's amongst entities.


    You seem to be thinking my argument is about 'Update'. My argument is about your claim that 10K objects equates to 10k renderers. Which it does not. But alas you like to keep moving the goal post around and ramble on about other things... back on subject here. 10k go's does not mean 10k renderers.
     
  17. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    Custom scripts can only be slow if they do something in loop or regularily (Update() and such or Coroutine). And that's exactly what we're talking in topic about, no? That's why I left them out from that quote.

    And will it be slow? If those objects do nothing on per-frame basis, only editor's list of objects will be slow when it needs to show all of them. And we're in Topic about Update() calls so I assume they do something on per-frame basis, so they have at least one Component with Update() or renderer or physics or such.

    No slow down yet doesn't mean it's efficient... At least you're doing about 50 extra small allocations(each transform is extra allocation you don't really need) on instantiate so instantiating 100 of them in one frame won't work nice. Also moving object behaviour tree is parented to will move all Transforms inside which does nothing visually in your case, but requires extra operations.

    Test performance on thousands on NPCs first. Most I've pushed out was about 2500 of my NPC's AIs on core i7 CPU(=~1200 on AMD A8-5600K). And I consider it badly-written. Can you make more without slowdown? Then I'll admit you've made an efficient monster. I can make extremely inefficient 100 NPCs that won't drop down FPS, but at least I won't claim they're efficient. And yes, I understand that you might never need this much and thus it's not efficient. Just don't claim it is when it's not.
     
  18. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    So wait, you're arguing that 10k objects would be slow, because of 10k renderers.

    BUT, they would also be slow if 10k udpates in the 10k objects as well?

    I'm totally lost as to what you're even saying here. So... whatever... sure.


    OK... so more memory is taking up. Memory increase doesn't mean it'll slow down the game.

    Sure the initial load might be slower.

    And, if I'm SHARING the BT, I don't have to reparent it. If it's unique to an entity, it's parented once... at load. If it's shared, it remains separate from each entity that shares it. Not understanding your point about this...

    Depends on how I structure it. When sharing BT's, it's plenty fast. If I made thousands of unique BT's it'd probably be a little slower.

    In the same respect, I don't NEED thousands. Just because something could be more efficient, doesn't mean mine is inefficient. There's trade offs to design... this one being simple for my designers to work with, so I don't have to muck about with them.

    I mean really dude... are you so annoyed that I refuted that 10k gameobejcts doesn't mean 10k renderers, that you just decide to smear my programming skills with little to no knowledge of how they work beyond a simple screen shot of the editor?

    Pfff... that's pathetic of you. You're arguing has devolved to what essentially is name calling. No longer entertained by your ramblings that result in goal post moving and name calling. You have a wonderful night.
     
  19. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    Yes, that's what I'm saying. So why care about Update calls?

    Then there won't be ever even 10.000 GameObjects with Update, not to mention we need at least 100 times more for Update() calls to become a real problem so what are you showing then using those pictures?
    I really don't understand why you posted those huge pictures showing nothing.
     
  20. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    I'm showing that you might have 10k objects with out renderers...

    how many times have I said that now?
     
  21. Teravisor

    Teravisor

    Joined:
    Dec 29, 2014
    Posts:
    654
    I'm leaving that offtopic as you didn't read that and still continue to push on.
     
  22. lordofduct

    lordofduct

    Joined:
    Oct 3, 2011
    Posts:
    8,514
    quotes statement made 4 posts after the initial statement I was refuting.

    A quote I actually quoted back to you AGREEING. I wasn't arguing that architecturally you would run into other problems. I totally agree... that was my original post. Go look, post #2 in this thread is me saying that.

    That wasn't my argument. You said:

    All I was saying is that just because you have 10k objects, doesn't mean you have 10k renderers. So this argument is superfluous.

    You went off on some other tirade... I don't know what. I tried redirecting you back to my argument. I even AGREED with the thing you just quoted from yourself.

    Whatever bro.

    You're right???

    ::shakes head::
     
  23. Suddoha

    Suddoha

    Joined:
    Nov 9, 2013
    Posts:
    2,824
    I didn't doubt there would be almost no noticable effect when having a normal amount of script instances, the way you started to argument just struggled my mind.

    You can't just go the way and say something like "you won't get into the situation in which this would help because Unity cannot deal with that many GO anyways". That's unrelated to the actual topic. Of course there has to be something that those are attached to but this amount of GOs varies alot due to design questions, so don't justify one thing with non-trivial other factors.

    And yes, I've already read that article before this thread came up.
    Millions? Why are you even talking about millions now? A big game may already take advantage of this kind of pattern, now you're trying (yet again with another exaggeration) to make it look as if this wasn't even an upcoming issue at all in any real game that could be thought off and be created with Unity.