Garbage Collection, Allocations, and Third Party Assets in the Asset Store

Check out this link, to a new Mono (3.0) API feature that provides a way to prevent the Mono.Runtine from doing a Stop-Everything-I'm-Collecting-Pause

http://schani.wordpress.com/2013/02/25/sgen-concurrency-and-evacuation/

 

For UT's benefit, I am in favour of extending/changing the API functions to access List<T>[] parameters as suggested by superpig so that the capacity can be increased to accommodate more results being added should the be required.

Basically though, whatever solution is implemented needs to minimize or eradicate allocation, be fast, and be memory friendly to reduce fragmentation.

 

This would be perfect.

 

If you feel like writing another test, I would like to know if using Physics.OverlapSphere is better/worse than doing a distance check on an existing list of transforms.

 

I did this test before implementing our own solution in Folk Tale. We went with a cached transform distance to avoid the allocation. The impact of the GC freezing all threads is far worse than the time it takes to run the distance check ( subject to there being a reasonable number of items and not checking say 10,000 distances every frame ).

 

Speed. I'm only interested in speed (doing a pc game, so care very little about memory at this stage)

example: All my vehicles register themselves on creation into a singleton class. When each vehicle chooses a target, currently, it calls into that pre-existing list and does distance checks to determine targets of interest (rather than using overlap sphere). Originally I had it returning another list to the vehicle, but that created a new list on return. Could have changed that to get around it, however for the moment, the decision on which transform to use is performed within the class that holds all the vehicle references.

So I have two choices. Each vehicle runs its own overlapsphere and chooses a target from the results, or it uses the current system that asks a manager class to tell it the best target. Ill probably stick with the latter solution since it gives me a richer set of information for AI purposes, but i'm still interested in knowing which is faster.

note: the list of potential targets is really only 50 max

 

Hi James.

"doing a pc game, so care very little about memory at this stage" is how we first started out, and with hindsight it's a bad frame of mind to adopt especially since Windows 32-bit machines and DirectX 9.0c are major memory chewers. Have a read of this guide over on Steam, which we had to write due to numerous memory related crashes for players on Windows 32-bit machines and the need to get players up and running. As a rule of thumb we'd recommend keeping your game below 1GB-1.5GB of memory consumption to avoid the issues we ran into.

What you describe is pretty much the approach we first started with. But instead of returning lists we populated pre-defined arrays to avoid the extra allocation ( capping the results set ). While you say speed is all that you are concerned with, you may discover that is not necessarily the best stance either - it is far more important right now to avoid per frame or frequent allocation that feeds the gc. Of course, we don't know your game, and your situation may be different. I'm merely highlighting what we've discovered over the 2 years of developing Folk Tale.

Another approach we took was for each character to have a sphere collider radar set to trigger. As enemies entered they registered with each other, subscribing to events such as Victory and Death. As they leave ( OnTriggerExit ) they de-register.

As for which is faster in your situation, you'd have to test.

 

I doubt my game will be out for a while yet (especially based on the current zero progress in around 2 months). Im not too fussed about supporting DX9 and lower users. Only counts for 3% of current hardware in the steam stats. By the time I finish, will probably be using dx12 (if theres such a thing in the pipeline)

I will spend time optimizing memory usage, but by the time im code complete, I only expect that to be in the non-script space.. textures/effects/etc.

I have spent plenty of time watching deep profiling of my scripts and removed a lot of redundant allocations, which includes using functions like Physics.OverlapSphere and replacing them with the way described above. Whether there have been significant improvements or not is hard to say, but it seems like its better, at least in regards to 'not feeding the gc monster'.

Im not a fan of using the trigger systems, but again, Im not sure if this is because I dont like setting them up, or if I dont like the un-reliability of TriggerEvents (previously a destroyed trigger didnt register a TriggerExit - doubt this has changed?).

It does bug me, that to find out the best approach I would have to spend time writing test scenarios.

Well done on this thread btw. Some excellent little tidbits in here.

 

True. It feels like minimising the colliders in my scene would be a more optimised approach. Granted I've already got 100's of rigidbodies/colliders flying through my scenes. Majority of profiler time is spent between physics/rendering currently.

Damn you 32GB rams... why you make me so careless...

 

So very, very true.

From what I understand DirectX 10+ removed the replication of GPU memory in allocated system memory so that will be a major help for you.

Another major gotcha is null pointer references. For some reason they didn't show on any of the team's machines, but caused crashes on some player machines, requiring us to do a full code audit post launch to find where we'd missed them.

e.g.

Code (csharp):

1.  
2. Transform t = cachedTransform.FindChild ( "Some Child That Does not exist" );
3. t.GetComponent<Car> ().speed = 200; // <--- CRASH because t is null
4.  

In most cases we'd already moved to defensive programming, but still missed a few:

Code (csharp):

1.  
2. Transform t = cachedTransform.FindChild ( "Some Child That Does not exist" );
3. if ( t != null )
4. {
5.    Car car = t.GetComponent<Car> ();
6.    if ( car != null )
7.    {
8.       car.speed = 200;
9.    }
10.    else
11.    {
12.       // if in game debug mode, log error
13.    }
14. }
15. else
16. {
17.    // if in game debug mode, log error
18. }
19.  

It results in code bloat but it'll avoid major headaches when your game gets into the hands of thousands of players by providing you with meaningful log output allowing you to quickly narrow down the issue, enabling you to be responsive with meaningful information that will result in a positive response from the player and win their patience. When potential customers are reading your forums to help make a purchase decision, being a responsive developer and quickly fixing bugs is a primary factor in determining continued sales success.

 

All my code... well about 95% of it is coded defensively, using LogError, or LogWarning for the stuff I want to know about being null. Ive always assumed that code bloat due to defensive coding had no effect on performance.

The only part that isnt coded in such a way is my pool manager, but the only time this falls apart is during a mid-game recompile.

 

Yeah the performance overhead is zero-to-negligible and far outweighed by the benefit. We use a DebugManager singleton with compiler directives that allows us to change the logging level, enabling us to quickly publish password protected builds in Steam that generate MB's of log data in rarer support cases.

 

That's something Ill probably have to consider as well... Hopefully I end up with enough users to actually require special builds. ha

 

true. I doubt im any where near those sorts of requirements tbh.

 

Eww these null check samples are really bad, you're completely killing your game's maintainability doing that.
It's much better to never handle null, instead fix the bug (if a component is missing, it's much better to find why it could be missing and fix all those root issues, than workaround the crash by checking if null is returned and then logging it leaving the game in a weird state)

 

I believe that the intention is to do both, as opposed to one or the other. Fix all known bugs so that the game works, but also code defensively so that your game has a better chance of gracefully handling the unknown ones.

Also, crashing the game is really unhelpful as far as maintenance goes. Logging something for your users to send you if the game breaks in the wild means that you at least know what you need to reproduce.

 

But i strongly with the "do both" way. You're more likely to introduce bugs by adding more code, so you don't want to code for "something that can't happen". What i'm saying is, if you're catching an error, instead code so that the error cannot happen >by design<, i'm not saying "pray and hope you don't screw up", i'm saying that, when you're doing what you're doing there (checking for a null) you already identified a problem "this method can return null". Map that to all the path that could lead to it and fix the logical flow that causes it, if you expect this component to be there, it should be there, are you putting it at design time? If so make a in unity check that will check it is there before compile. Is it added at runtime? Use an extention method that will throw if it's not there. Doesn't matter if it's not there and all you're doing is creating it? Remove the checks and create a GetComponentOrCreate method.
It's always a bad idea to write 10X the code to catch potential errors that you're just guessing could happen, literring your code with checks doesn't make it more robust if you're doing it out of principle, it's actually well known humans do a pretty close to fixed amount of errors "per line" of code, more code = more bugs.
I don't write null checks like, ever, except in the few cases where i'm faced with an API that i don't own and that can send null as a meaningful functional result, and i never had a single bug / issue caused by that, if something should not be null, make it so it cannot be null, don't check if it's null everywhere.

 

I'll respectfully decline to agree. We need debug aids right now to help identify and fix issues that *potentially* could affect thousands and thousands of players. By adding these checks in now, we're able to quickly isolate and fix problems. In time we may be able to ease back on some of it, but for now the ability to respond quickly is critical to our commercial success. Practicality beats idealism in my experience, but that's a subjective opinion just like code maintainability.

 

It's not idealism, it's just raw good design, i'm not saying it idealistically, i actually design like this and it's much more practical, you end up with less code, less bugs less bloat, how is that unpractical and idealistic? It's also fairly trivial to implement, the examples i gave you of making an extension methods are both faster to implement and cleaner than your version, and they solve the issue instead of logging it. They "remove" the issue, how can you think it's better to "have the issue and log it" instead of "removing it"?
Note that even if you want to log it it's still pretty horrible design wise, lets say you want to log it anyway, what then is supposed to happen if you're missing that component don't fix it yourself? If you fix it, may as well do it once for all in the extention method, if you don't fix it, may as well move the logging to the extention method too, this code is horribly bug prone, more code = more bugs.

 

Indeed. If something should not be null I'll do as you suggest and make sure it can't be null. And then I'll check it anyway, because even if I'm 99.9% effective at making sure things aren't null when they shouldn't be, one day I'm going to miss one.

Furthermore, I am not going to create a logic bug by writing something like...

Code (csharp):

1.  
2. if (x == null) {
3.     Debug.LogError("ClassName: x is null.");
4.     // Ideally followed by some code that fixes the problem, since you now know it's there
5. }
6.  

And then if someone contacts me and says "your game is crap, it goes nuts / crashes / won't let me do blah" I can say "Sorry about that, please send me your log and I'll get right on it." And I can look at the log and see "well, darn, x is null in this class. What did I miss that could have let that happen?" And already 80% of the debugging time for the error is done, because I know where to look for an error instead of... what... brainstorming potential causes?

And this will work 100% of the time, as long as you assume that there will never be a bug in any of the code that makes sure a value can not be null.

 

Why are you assuming we're not doing both? I mean, that's even how the conversation started. We're not saying "log the error and get on with things", we're saying "do your best to make sure the error doesn't happen, and if it does try your best to fix it (and probably still log it), and if you can't fix it log that".

What you're saying is essentially "solve problems by designing and writing perfect code that doesn't have problems". And seriously, if that was practically achievable in everyday life we wouldn't be having this conversation.

 

You've got things backward, i'm not talking about begginer level "oh yea i'll double check it's not null rawr!" type of mentality, i'm talking about making things not null >BY DESIGN< that is architechture your stuff so that nullity is not possible period, not "not possible if it follows the correct code path".

Actually the same you showed is EXACTLY what you're doing, checking for null then logging, and it's EXACTLY what i suggest you >DO NOT DO< what i suggest is you fix it once for all by never calling GetComponent, but instead doing something functionaly sensible which does one of the following (depending on your taste):
- Logs the error (if you really insist)
- Actually ensures the element is not null if it is create it (a single check, for your whole program, once in a generic method, not 100s of times everywhere in your code)

 

I strongly disagree, you can't pre fix bugs (attention errors) but you can definately by design bugs (that is, writing bad code by design), my stance on this is the code you show is bad code by design, because it introduces errors due to verbosity, which are very much solvable cleanly and in a generic way by design

Edit : And i also disagree with doing both, if you're saying "oh let's check if it's not null anyway" then you're saying "i have no clue why this should be null, but i'm going to check anyway and fix it", if you're "fixing a state" and you have "no clue how you got into that state" that's bad programming to me. You just don't try to fix errors without thinking they can happen, if they happen then your whole code is brittle really, it just shouldn't happen, i'm not talking "ideally" or "in a wonderful world" but from experience, it just doesn't happen, if it does, it's bad design or bad language level, not attention errors.

 

You can call it "by design" as much as you want. Fact is that you will still one day make a mistake.

And the point of my code example wasn't to show you how it's done, it was to show you that the type of code that we're taking about can't introduce a logic bug, at the same time as letting you know if something else has introduced one.

 

No, as i said you're mixing 2 things, bugs that happen due to inatention, and bugs that happen by design, the cause of both isn't the same, i haven't had a single instance of bugs due to this since i program profesionally full time in C# (7 or 8 years ish?) not once, hey let's say you're right and it happens once, i'm still happy i didn't nearly double my code size during 8 years to prevent one bug, once (that hasn't even happened untill now) because i'm 100% sure i'd have introduced many more during that time, and i still feel strongly, from experience, that i simply cannot introduce a bug that way.

Sure if you program today like you did 10 years ago+ it can happen, if you program in a modern way, it can't happen, by design, if you're still worried it can happen, use code contracts to avoid nulls, code shouldn't have to "check for error" everywhere, if it does, it means the >PRODUCER< of the called code (not the caller) didn't do his work right. If you call a method it can return null, rewrite it call that instead, if a method can't return null be design but still does, it's a crappy method the problem lies there, don't fix it everywhere you call it, fix it where the fix belongs, inside the method, else you're not programming, you're not making a game, you're making a very large unit test for the framework you're using, and that's not time well spent in my book!

 

Maybe you two should start a new null thread instead? : p

 

But you're talking about "pre fixing" yourself, just in a different way. But you're also talking about doing it silently, which is the bit I disagree with. If I call a GetOrCreateX() method and it silently creates X because it wasn't there, then there's potentially still a problem.

The difference is that I'll log that there was a problem, where you're going to pretend it's not there because you've "designed it away". You're perfectly correct that you should know about errors before you can fix them properly. The difference here is that I'm leaving breadcrumbs so that I know where they happened so that I can fix them properly, where you're pretending they're not there and saying it isn't a problem.

 

That wasn't the intent, to be clear it's not the "logging" that i mind, it's the "there's an error and i'm going to fix it here althought i've got no clue why it happened" instead of "i'm calling this method and it will work period, and that method has the job of fixing itself". What makes me scream is litering those null checks everywhere in your program instead of having correct wrappers everywhere.
I'm not pre fixing it, i'm just not causing it, you're calling a function that says "i will return this component and null if the component doesn't exist", i say do something functionally sensible if you want to self fix it and make a function that clearly says "i will return this component if it exist, and instantiate it (and log it if you want , that's not the part i'm concerned with) if it isn't there".

Basically change
var q = GetSomethingOrNull()
if(q == null)
{
bla
}
else
{
bleh
}

to
var q = GetSomethingOrDefault();

 

Null is the specific point here but it could be many other things, my take is "don't let a method give you something incoherent and fix that, make the right method first and fix it once"

 

Which is programming 101. And it's awesome and works 100% of the time, assuming that you don't ever write or design an error, and don't ever work with anyone else who might. I personally accept that I'm not perfect, and don't expect perfection from others that I work with, and so we work accordingly.

 

I actually don't write or design an error, not work with someone who might, in those specific cases, it's also design 101, why would i work with someone who'd do those errors?

 

Doesn't it still hide the problem? I mean, for example you need to get an object's collider to do some manipulations with it. There are three ways:

1.

Code (csharp):

1.  
2. var collider = GetComponent<Collider>();
3. collider.someProperty = someValue;
4.  

If there is no collider, the second line will throw NullReferenceException, it will be automatically logged and you will know the exact place where it have happened.

2.

Code (csharp):

1.  
2. var collider = GetComponent<Collider>();
3. if (collider == null)
4. {
5.     // a) log the problem
6.     // b) do something reasonable in the current context, for example, create and setup exactly that type of collider that would make sense for this type of object
7. }
8. collider.someProperty = someValue;
9.  

3.

Code (csharp):

1.  
2. var collider = GetComponentOrDefault<Collider>();
3. collider.someProperty = someValue;
4.  

Shouldn't I still place a check in the middle?

Code (csharp):

1.  
2. var collider = GetComponentOrDefault<Collider>();
3. if (collider == defaultCollider)
4. {
5.    // do something reasonable in the current context
6. }
7. collider.someProperty = someValue;
8.  

Since GetComponentOrDefault has no clue where it is called from, it can't always return the collider I need, it returns the default one. And since the game state is already broken I may get multiple exceptions and silent errors later. I don't see how it is better than returning just null if there's no collider for some reason.

 

It's a mater of a clean API, it doesn't have to map 1:1 to the unity API, if you want a GetComponentOrDefault for a type which may require configuration, that info needs to be passed in, you may also not want to fix it in place if it's not possible for it to be configured in place.

My overall point is, bad programming is checking for everything (possible or not) all the time with no reason. Good programming is knowing the set of things that can go wrong, that's why Exceptions are named Exceptions, not because they're here for everything, but because there're here for the few exceptional cases you've decided you can't handle internally.

If you needed a specific collider you should be able to do GetComponentOrDefault<MeshCollider> or <SphereCollider> for example, it can't be guesstimated by the function otherwise.

 

Sounds reasonable, thanks.

PS
Maybe it's possible to organize all the code the way where the absence of a collider or any other component is just a regular situation (they don't exist by default and use lazy initialization), not something extraordinary that requires special handling and logging.

 

It shouldn't need to care where you're calling from, and that is a design thing. But personally, if I expected there to be a collider there and for some reason there wasn't, then I don't want the method to silently fix the problem under my nose and pretend it wasn't there.

The main difference between ronan's position and mine is that I (may) see the lazy instantiation of a Collider as unexpected behaviour and I want to know about it so I can fix it, where ronan calls it expected behaviour and does not.

 

Not exactly no, what i'm saying is that anything you do past something not having the expected behavior is pretty undefined, here's you're not a master of the API, alas unity is, so you have to settle for something lesser. So what i'd say is that i take the least evil workaround, i'd say "i'm calling a method that will return a collider, which may or may not be the one i expected to be there, but that will provide a functionally equivalent base to work with" instead of "i'm in a bad situation, but i will fix it locally, even thought i have no idea what caused it". Basically the method (both it's naming functionality) is "honest" about it's best effort, it's not saying i will fail on you, it says if i fail internally, i will provide you with something functionally acceptable. My take is that you shouldn't know as the caller that it failed, because it's not your business, you're not even supposed to know how it acts internally, if you ask it for a component, it provides one. That sounds functionally reasonable.

However that's a workaround (that's how i'd design around unity, not how i'd design normally, normally i wouldn't handle anything in there, because the whole chain of function would be coded that way so that such wrong state cannot happen, here the method handles a state unity gave you, can't do much about it but mitigate it, ideally you wouldn't have methods that give you weird states to begin with)

 

But you absolutely should know that it failed! Why did it fail, and does it indicate a problem elsewhere?

Like I said, if I expected there to be a collider there and there was not then something went wrong and therefore I want to know so I can fix it! I mean, sure, add a new collider, this part of the app will now hopefully work 100% as expected, so there's no problem... here. But something caused there to be no collider where I thought there would be one, and I don't want that covered up.

I agree with what you said earlier about knowing for and checking errors relevantly. I won't check whether something is null or that its value is valid if I know that it can't possibly be otherwise. But my criteria for that seem to be quite different to yours.

 

I'm not saying you shouldn't want to fix it, i'm saying if there's somewhere where you should fix the issue of there not being a collider, it definately makes a whole lot more sense there than in your local code.

If your function is called CheckCollision, it should check of collissions, not for missing objects, however a GetComponent method definately sounds like the right place to check if a component is missing and to fix it too!

So let's say you'd like to fix it, what exactly are you going to do to fix it in your local method with no clue what happened? What except to create a collider which is just what my method does, except it does it in 1 place?

Also if you really want to do something / fix / log custom etc on error, at the very least instead of local code i'd leave most of that in the function and simply pass some additional code to run on error

go.GetComponent<Collider>((col)=>// do whatever you want to do here in case of error on the colider object that has been created for you);

 

Ok then. And how do I know that there's anything to fix if I silently sweep it under a rug?

 

The answer is in the unquoted part of the sentence, you fix it, but not from there!

 

Haha, no, that's not what I asked.

 

Then i honestly don't get your question, can you clarify?

 

I am going to be the scapegoat. Please guys, your discussion is getting more and more off topic.

 

On one hand you're right, on the other hand it doesn't really matter as this was a dead thread, revived in hopes someone at unity would answer, that is just waiting to die again, so it wouldn't really be that different if this was a new thread anymore; but yea i'll agree stoping this discussion here, will be happy to continue it a new thread if anyone cares.

 

As someone who searches regularly for specific topics in this forum, I think it makes sense to have those discussions in different threads. It can be extremely time consuming to search for specific information in a thread if there are unrelated discussions going on.

 

You must be one of those coders that can write bug free code... I heard they were just a myth. Probably a good thing that everyone that worked on developing Unity is also one of these mythical beasts.

Null checking is a way of life, unless you can prove beyond a doubt, every function in Unity is perfect.

Edit: Also, Unity runs on top of Windows... tell me again that code bloat is pointless...