-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TracePoint is slow #18
Comments
Currently TracePoint doesn't provide such API or configuration and the official debugger
You need to throw those calls away even in C-extension/VM level too, no? So the only difference is at which level we do the path comparison and early return. While implementing the filtering logic in C-extension, or at VM level through new APIs might increase the performance, they both come with maintenance cost on the gem or even CRuby itself. Therefore, as the only maintainer of the gem, I'd like to work on these fronts first before investing in this optimisation:
So to summarise, I understand your concern about performance and I appreciate that you're raising the issue. But given the limited adoption on this gem and the resource I have, I'm not able to prioritise this now. |
Optimally, the TracePoint class would only instrument those methods upfront that met the path filtering criteria. This is similar to the approach that I did with Call Stacking - overriding upfront only the application-level methods in a module and then pretending the module to the class. To deinstrument the methods, they are simply removed from the prepended module. It'd be nice if the selective method instrumentation were done at the VM level so that I could use the TracePoint implementation. I don't know enough about the C internals, yet.
I'm working towards better awareness of trace style debugging with my app Call Stacking ( https://callstacking.com/ ). |
Is there any way to have TracePoint do the path matching, instead of:
https://github.com/ruby/tracer/blob/master/lib/tracer/base.rb#L144
Then it would be at the VM level, which should provide a performance increase.
Could be achieved with a C extension?
Otherwise, you're throwing away 99% of the method calls that aren't application-level, and it makes for incredibly slow tracing.
The text was updated successfully, but these errors were encountered: