BEPUphysics

Hello i would like to notify that the DebugDrawer.RemoveBody generate garbage.

It's planned to be fixed ? or it's normal maybe(don't know)

Around 77,064 bytes in 4 seconds for fews calls to this functions.

Thank you.

The 'instanced' model drawer is more of an 'aggressively batching' drawer. This involves combining vertex buffers. Removal simply reconstructs a batch, which is expensive and garbage-producing.

The BEPUphysicsDrawer project is intended for debug/demo visualization where the garbage doesn't matter. The demos avoid adding/removing on the fly, and debug usages are not performance sensitive. So, this is expected and there are no plans to change it.

Ok thank you, for the fast answer

But for performance tracking it could be bad, (of course in final it will be not DebugDrawer) but for tracing memory it could be good to avoid this leak, but anyway it's your soft and if you won't plane to fix this, i'll just existing.

But for performance tracking it could be bad, (of course in final it will be not DebugDrawer) but for tracing memory it could be good to avoid this leak,

It could indeed interfere with profiling, but only if there is no proper rendering alternative. Debug visualization should be disabled for performance and memory profiling since it's not actually a proper part of the application being measured. Its primary purpose as a debug visualizer is to ensure that collision shapes match closely enough to graphics or to investigate behavior oddities which the normal graphics may obfuscate. Using it as a primary graphics system is strongly recommended against- though I admit to doing it for side projects (knowing precisely how it can backfire)

Thank you.

I see that for example the function GetNarrowPhasePair generate garbage too and use Activator Create Instance...(10x more slow that new..:p)

So maybe there is a way at the beginning to define Pool Size?

I see that for example the function GetNarrowPhasePair generate garbage too

That method should not generate garbage. It will, however, allocate if no object is available in the pool. The engine must scale up its resources to handle larger simulations with more collisions. Those allocations are either in use or in a pool, so they're not garbage.

Note that allocations alone are not a significant issue. Allocating a bunch of data does not directly result in garbage collections of that same data later (although it may trigger garbage collections of other now-unused data or compactions to make room); it must first go out of use.

A secondary consideration is that a more complex heap can make GC take a bit longer, but it's usually better to just avoid causing a GC under normal circumstances. Making the heap simple enough that a GC runs smoothly without dropping a single frame ever can be very tricky (or impossible), especially on the Xbox360.

and use Activator Create Instance...(10x more slow that new..:p)

In the engine itself somewhere? The narrow phase factories and pools use generic new constraints, not Activator.CreateInstance. There's a few Activator uses in the BEPUphysicsDrawer, but they're irrelevant compared to the rest of the costs involved.

[Edit/Note: It actually looks like the CLR v4 generic new constraint is still using a form of Activator.CreateInstance internally. I might eventually do something fancier, like emitting and caching a function to construct the type, but it's not generally a bottleneck anyway.]

So maybe there is a way at the beginning to define Pool Size?

Yes, every pool can be given an initial resource count. The narrow phase pair factories are the easiest to reach and initialize in the NarrowPhaseHelper.

There's reasons why setting the initial sizes can be useful:
-The simulation is expected to expand extremely rapidly. Creation of objects is fast, but if there's a giant tower of blocks destined to fall into a pile with 50,000 collision pairs, the factory might as well be primed to move the object creation cost to load time.
-While the GetNarrowPhasePair method and other pool-requesting methods do not create garbage, returning objects to their pools once the simulation quiets down can force internal list resizes in the pools. This form of garbage is usually quite rare and inconsequential. However, careful initialization of the resource pools can avoid it if really needed.

Ok thank you for your answer

Another question:

Have you profile your engine on xbox too? Because on my PC the GC.GetTotalMemory is near const while under xbox i have a GC.Collect around each 5 seconds.

In my code i don't detect a lot of changement between xbox and PC but maybe in your engine there is a lot of change for xbox that it could generate garbage?


Thank you

Have you profile your engine on xbox too? Because on my PC the GC.GetTotalMemory is near const while under xbox i have a GC.Collect around each 5 seconds.

In my code i don't detect a lot of changement between xbox and PC but maybe in your engine there is a lot of change for xbox that it could generate garbage?

Yes, it has been profiled on the Xbox360. The last time it was checked, there were no issues. There are not many changes between the Windows and Xbox version as far as GC would be concerned. If you locate a specific system that's creating garbage that shouldn't, let me know and I'll look into it.