TracePoint is slow #18

Activity

1. st0012 commented on Jul 8, 2023

   

   st0012

   on Jul 8, 2023

   Member

   More actions

   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.
2. aantix commented on Jul 8, 2023

   

   aantix

   on Jul 8, 2023

   Author

   More actions

   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.

   https://github.com/callstacking/callstacking-rails/blob/main/lib/callstacking/rails/instrument.rb#L16

   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.

   How can we make this tool and the concept of tracing more widely adopted?

   I'm working towards better awareness of trace style debugging with my app Call Stacking ( https://callstacking.com/ ).