Skip to content
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

Open
aantix opened this issue Jul 7, 2023 · 2 comments
Open

TracePoint is slow #18

aantix opened this issue Jul 7, 2023 · 2 comments

Comments

@aantix
Copy link

aantix commented Jul 7, 2023

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.

@st0012
Copy link
Member

st0012 commented Jul 8, 2023

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
Copy link
Author

aantix commented Jul 8, 2023

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/ ).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants