(Unity) Add Profiler support for the C # implementation that is blocked by Lua

Problem description

The Unity project often chooses to use Lua as a more logical script in practice. This is because Unity itself is less friendly to heat, more flexible with Lua heat, and simpler to share code and data with the server. At present, many different Unity + Lua integration programs, the practice of using a lot of Pang classmate's Slua program.

Teams that use Lua tend to be "heavier" integrations, exposing a sizable engine interface to Lua, so logically enough freedom to have full control over the game and the engine. When the interoperability interface between C#/lua rapidly grows to tens of thousands, an important issue emerges: C # and Lua's interaction layer is closed to the engine, and many engine-built tools do not cross the boundaries of host (C #) and script (LUA). The most important of these affected mechanisms is Unity Profiler.

Unity Profiler is a powerful performance analysis tool provided by unity, which can effectively help locate bottlenecks in the optimization phase, and sometimes it is easy to find some hidden bugs. And when we navigate to a Lua function that has a larger overhead (CPU or memory GC Alloc), it's hard to see more detail as the effects of cross-language boundaries are blocked.

A "normal" approach

Since the API interface of Profiler is also exposed to the script, it is normal to turn to the corresponding Lua code according to the problematic calls on the C # side, read the relevant script logic, and add the corresponding profiling samples for the potentially expensive logic. Profiler.beginsample ()/endsample (), to locate the problem code paragraph, and then back to the corresponding C # function, and then add the test code to verify our ideas.

In fact, we know that in most cases (if not a bug), the CPU overhead of a logical script is relatively low compared to the engine part (in the case of the logical code, the majority of the cases that require loops are very small, and generally do not use very complex calculations-or, in the case of proper design, Complex operations are given to the bottom to do the whole block, and the easily troubled managed memory allocations cause the GC cotton memory problem, as well as the C # code that is completely returned by the script.

This analysis, often around a circle and back to C #, the middle pay a lot of meaningless in the script in circles of time not to say, was forced to read and analyze the repetitive high script logic code, also greatly increased the burden of energy and mental.

Aop

Now that you know it's always going to go back to C # from Lua, is there a simple way to add a profiling sample to all of the C # interfaces exposed to LUA once and for all?

If we can do this, we can ignore the intermediate script layer (LUA) interference and solve all the problems within the C # environment.

My gaze naturally goes to AOP (Aspect oriented programming), which helps us to add the code we want to execute without modifying the target function code (like Python's decorator).

Python-deco

After some research, I succeeded in drawing the following conclusion:

Some existing AOP methods for C #, under the Unity of the mono, basically kneeling ~ ~

Still can let me have a happy children's Day ~ ~

In these attempts, the closest success is to use a lambda expression package layer, add the relevant code, and then register it to Slua, however, Slua need to add the following attribute for the registered function:

[Monopinvokecallbackattribute (typeof (XXX))]
C # does not support adding attributes to lambda expression, so &_& ...

A concise approach to using Slua code generation

Finding it difficult to solve problems through the language mechanism of C # itself, I looked to Slua: Now that all the binding code is Slua generated, it's better to modify the generated code directly and generate the sample code into the binding function of the interface.

Locate the build location of the normal function interface

void Writefunctionimpl (StreamWriter file, MethodInfo m, Type T, BindingFlags BF)
{
...
}
At one end add the corresponding generated code (beginsample () parameters can be directly with methodinfo.name to get the correct function name), run Slua make generated, get the following results (a single function):

[Monopinvokecallbackattribute (typeof (XXX))]
static public int xxx (IntPtr l) {
try {
Profiler. Beginsample ("xxx");

...

return 1;
}
catch (Exception e) {
Return error (L, e);
}
finally {
Profiler. Endsample ();
}
}
Endsample () in finally, ensure that each exit is matched correctly.

Particle size Control

Next step further, we want to have some granularity of control, only for a class of interest, or even for functions that are cared for within that class. Back to the method where the previous function was generated, you can see the signature:

void Writefunctionimpl (StreamWriter file, MethodInfo m, Type T, BindingFlags BF);
The second parameter can be used to filter the functions we care about (we can filter the strings with M.name), and the third parameter Type T can be used to filter the corresponding class (through the if (t = = typeof (Targetclass)) so that we can only Generated for a particular class and function.