Concept
Whether you profile a section of code or log an event, the collected data is stored within a slot. Fortunately you don't need to deal with slots directly, they will be created automatically while you store debugging data. All slots will be addressed by their identifier, much like a name, but identifiers are more clever:
Identifiers
Identifiers work like namespaces, so by nesting them you can determine how the data is presented in the detail section's tree view. You don't need to nest your slots at all, but they'll help you organize and filter the amount of debugging data.
Need an example? Well, let's say you've got several game objects with the same script attached to them and you want to check how long their Update() and LateUpdate() methods takes to process:
void Update()
{
using (new MIPProfiler(name+".Update"))
{
// your update code comes here...
}
}
void LateUpdate()
{
using (new MIPProfiler(name+".LateUpdate"))
{
// your LateUpdate code comes here...
}
}
If you run this and look at the data readout, you'll see a treenode for each GameObject (Alpha and Beta), each containing two sub nodes Update and LateUpdate.
Nice, ain't it? So, by nesting Identifiers like this you can organize your data in a very smart and clever way.
To expand the above example, imagine Alpha and Beta being enemies and you'll have a dozen of them, bloating your data readout. You've got several ways to deal with this amount of slots:
- Remove the name from the identifier: as a result \e Update and \e LateUpdate of all enemies will summarize their times to the same slots.
- Add a prefix like "Enemy" to the identifier and filter the output to hide all or some enemies.
>> Profiling