Visal debugging performance

[FNGgames]

Ideas / suggestions for a "performance mode" version of visual debugging (VD).

Problem: VD currently very demanding for a large number of entities due to the cost of creating and destroying the gameobjects used to represent them.

Here are a few of my thoughts:

1. Pool the gameobjects used for VD

2. Create only the root systems inspector gameobject by default then add buttons to "expand" or "collapse" sub-features which would create/destroy the child gameobjects that represent the sub-features (though i dont think systems profiling is the real culprit here)

3. Create no gameobjects for individual entities, instead, just use the single context gameobjects by default, list all the currently defined groups in the inspector, list their entity count, then provide a button to debug the group which would then create the gameobjects as usual, but only for the requested group. Remove the gameobjects again when the debug group button is unchecked.

4. Allow on-the-fly custom groups to be made and then debugged as in (3). This could perhaps be done by providing 3 arrays to fill, one of the components in AllOf, the second AnyOf and third NoneOf. Generate the group by assembling it from those pieces then provide the "debug this group" check box as before.

5. ToString() for every component to produce the name for the gameobject seems a bit heavy and wasteful, maybe there's a better way to search them, instead of using unity's string search field, perhaps we could use groups as described above instead. Then we could get rid of the need to ToString the entities to write their names out (again, no idea whether this is an useful optimisation or not, just thinking aloud).

Ideas / comments welcome.

[WeslomPo]

Huge problem that name for entities generates every frame by ToString (5 problem in the list). This is first that need to be fixed.

[CCludts]

Out of curiosity, did anyone do some in-depth profiling to figure out what makes VD so heavy? A quick glance at the profiler seems to suggest ToString is the main culprit in our project (agreeing with @WeslomPo). Seems slightly strange, since ToString already has a cache built-in, and shouldnt be that expensive.

The way we 'fixed' things in our project is by disabling VD, and have a button to enable to at runtime. It's a mediocre fix though, it would be awesome if there's a low-level modification to make it more performant with large amounts of entities.

[FNGgames]

The cache for ToString is likely overwritten every frame if an entity changes at all, it has to walk every component and build a string out of all their ToString values. Just guessing here though, didn't look at the source.

[roygear]

The bad boy is ToString() in Update().

Here is my solution:
In class EntityBehaviour, use delegate OnComponentAdded and OnComponentRemoved instead of Update(). That will greatly reduce the calling of ToString(). After change, I can run 3000+ entities which contain 10 components smoothly in my test scene.

Source :
https://gist.github.com/roygear/f7eae9fe2f13792f0468657aa4428c31

Compiled dll based on 1.8.2
Entitas.VisualDebugging.Unity.dll.zip

[sschmid]

EntityBehaviour can be expensive when there are thousands of entities.

• Updating the GameObjects name is expensive
• If the Entity changes each frame entity.ToString() is very expensive

For comparison:
left: as is right now
right: no ToString()

[sschmid]

I tried not to change too much and do small improvements. By simply ignoring component.ToString(), which is probably not often used (e.g. Entity_0(*1)(Position(1, 2, 3))), we can safe 40% already.

[roygear]

In fact, the full component names cannot displayed on vertical layout. There are 10 components on the left, but displayed 3 to 4 maximum usually. Now, I have the right one.

[mchamplain]

Maybe setting a name when creating the entity would be more useful that displaying the components names?
var e = gameContext.CreateEntity("player");

[sschmid]

btw, the main reason I include all components is to able to search and filter entities

[zhuchun]

Good post! There're only a few entities in my current project but every time I click on any entity the inspector will be frozen for half a minute, I guess these are related.

[FNGgames]

btw, the main reason I include all components is to able to search and filter entities

What do you think about susing groups to choose which things get displayed?
You could have an "all" option or narrow them down by group?

[sschmid]

Hi, you might wanna pull from
#799-visual-debugging-performance

• reduced e.ToString() cache invalidation
• always using component.ToString()
• added object pool for EntityBehaviour

I'd like to have some feedback from you guys, if the performance is better and if it's good enough, or if there are more areas that need opimization. Thanks!

[sschmid]

You're still able to use the hierarchy search and custom component.ToString() still works, but the overall performance should be way better now.

See diff
https://github.com/sschmid/Entitas-CSharp/compare/feature/%23799-visual-debugging-performance

[FNGgames]

Are you going to merge this into release in the future? Thanks for responding to this issue

[sschmid]

Yes, that’s the plan. I just wanted to hear feedback already because I don’t have projects where visual debugging is an issue.

[sschmid]

For your convenience, here' a precompiled version of the latest version incl. the Visual Debugging improvements:

Entitas.zip

[sschmid]

Any feedback welcome ;)