Feature Request - Performance Logging/Profiling support

[edokan]

Hello,

I want to profile function and property calls to CLR objects. I looked at the code and saw that most of the points I can hook (ObjectWrapper, TypeResolver, etc.) are either sealed or do not let me intercept calls. I tried using Debugger by stepping in, but it calls me only before the call and does not work for properties. I cannot use a regular profiler like dotTrace for various reasons, including security.

Is there a way for me to be able to log/trace function calls/property fetches to CLR without changing the source code, which I'm open to but prefer not to in a sizeable project without a good grasp of the things?

Best regards

[lahma]

I don't think there would be a way to reliably trace or handle all possible paths via code. So traditional performance profiler would be the way to go.

[edokan]

I hear you, but it is not possible in my case anyway. The system I'm trying to profile runs a few hundred scripts a few thousand times an hour. It detects the scripts slowing down or having performance issues and logs them. What I want it to do is to automatically profile if I detect a performance issue so I can pinpoint issues.

In my humble opinion, if I can inherit from MethodInfoFunctionInstance and make Jint use it, I can easily log the Call method calls, which forces me to inherit from MethodAccessor, which in turn forces me to use new TypeResolver and ObjectWrapper; and same goes for other accessors. If I can make Jint use my classes, it can be done.

If I make a PR for this, will it be accepted, given that I follow your coding guidelines?

[edokan]

And I know that this still will not cover all cases, like Setvalue delegates.

[lahma]

My suggestion would be:

• making ReflectionAccessor public, but keeping current implementations internal
• make TypeResolver public
• having single point where accessors are created, TypeResolver.GetAccessor is there already and seems logical as public virtual point to produce them
• you could create own DecoratorAccessor inheriting from ReflectionAccessor and override the above method to return the decorator encapsulating the one Jint chose and logging in DoGetValue and DoSetValue, delegating to inner implementation
• tests in Jint.Tests.PublicInterface showing usage and ensuring we don't accidentally break the API surface

If that (or some variant) sounds plausible, maybe a PR then? This would cover the interop side at least.