Merge lp://qastaging/~unity-team/nux/nux.fix-gradual-degrade into lp://qastaging/nux/2.0

Wouldn't using a std::set or std::multiset be more sensible than vector?

> Wouldn't using a std::set or std::multiset be more sensible than vector?

There are better data types to use here for sure. set or multi-set don't really fit the bill however since we are storing single values, not key-value type information. A heap or tree of some sort is probably where this should end up. On most systems the number of elements (now) will hover around 300 to 1000, so there is no huge pressure to get to log(n).

Either way, those types of changes should be evaluated for a future merge proposal. Further I think it's worth considering turning this class off entirely in release builds. It doesn't really do anything in a release build anyway.

Right now you should be able to remove _texture_2d_array and _texture_rect_array without affecting the logic at all. They don't appear to contribute to the logic (!)

Re: "set or multi-set don't really fit the bill however since we are storing single values, not key-value type information"

You're getting your templates confused. set and multiset ate not key-value types at all. You're thinking of map and multimap.

> Right now you should be able to remove _texture_2d_array and
> _texture_rect_array without affecting the logic at all. They don't appear to
> contribute to the logic (!)

They are used when printing out texture ID's that were not run at the end of a debug build. This is why I say we could turn them off in a release build.

I meant to say texture ID's that were not free'd

set<int> (or multiset<int>) FTW :)

> Re: "set or multi-set don't really fit the bill however since we are storing
> single values, not key-value type information"
>
> You're getting your templates confused. set and multiset ate not key-value
> types at all. You're thinking of map and multimap.

Indeed I was. Sorry.

It does appear set<int> is a very straightforward way for us to get a BST. That probably would provide the needed performance if we never fixed the bug in the first place. That said, it still needs to be done in a different merge.

On the other hand, if set<int> was used in the beginning, we would not have noticed the find() being slow and the leak/bloat (root cause) would have gone unnoticed for much longer.

Wait, no. set<int> would have avoided the leak/bloat completely. multiset<int> would have still bloated with unbound memory use. But either template would find() so efficiently that the bug would never have been noticed as CPU use.

This doesn't look like it'll make any difference to me. Why does this fix the problem?

I think the important fixes are:
+ if (id)

preventing the vector from filling uncontrollably with id==0 objects.