st0012
commented
1 year ago Currently TracePoint doesn't provide such API or configuration and the official debugger ruby/debug also implements filtering at TracePoint level. So I don't see an obvious way to get around it.
Otherwise, you're throwing away 99% of the method calls that aren't application-level, and it makes for incredibly slow tracing.
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:
- How can we make this tool and the concept of tracing more widely adopted?
- What other features could be beneficial to our users under the current performance profile?
- Can we use this gem's usages to convince and work with CRuby maintainers to provide more generalised optimisation on TracePoint?
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.
aantix
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.