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

Will using rlang::global_entrace() in production code incur a (significant) performance reduction? #1717

Closed
dlaehnemann opened this issue Jun 12, 2024 · 2 comments

Comments

@dlaehnemann
Copy link

I have searched the rlang docs for rlang::global_entrace and had a look at the actual rlang::global_entrace() function code, but don't understand the code enough to arrive at an answer to this question by myself:

Would calling rlang::global_entrace() in production code / scripts incur a noticeable performance reduction?

Or, to put it otherwise:
Would you recommend putting this in all of our scripts, for immediate debugging output once problems occur? Or would you instead recommend to only add this while debugging, so after finding an error and only while digging into it?

@lionel-
Copy link
Member

lionel- commented Jun 12, 2024

It only incurs a small performance cost on unhandled errors, so it should be fine to use in your scripts. But please let us know if you find that this is not the case.

It's mostly meant to be used in personal Rprofiles rather than scripts though.

@dlaehnemann
Copy link
Author

Many thanks for this useful (and quick) assessment, that's very much appreciated.

And maybe some more context from my side, in case your curious why I'm asking: I'm working in bioinformatics, where lots of the packages come with very mixed error handling and we use lots of different packages all the time. There, with package version changes, complicated dependencies and changing reference datasets, you have quite a lot of opportunities for stuff to throw unhandled errors unexpectedly.

So for now, I think I'll probably opt for using rlang::global_entrace() in any scripts that go beyond just loading the library("tidyverse") and doing some simple data cleaning or plotting... When things go wrong unexpectedly, I should at least get a useful backtrace. Many thanks for providing this!

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

No branches or pull requests

2 participants