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

Ability to completely remove logging code (likely with a feature flag) #2224

Open
timboudreau opened this issue Aug 29, 2024 · 2 comments
Open

Comments

@timboudreau
Copy link
Contributor

The Problem

I am using uniffi with some code that does DSP - called from C, Objective C and Swift, and using the os_log crate to integrate the log crate, which uniffi's generated code uses, with Mac OS's system-level logging.

The code uniffi generates logs every inbound call into Rust - due to the lines visible in this diff

That might seem reasonable, assuming logging is zero-cost when not enabled (it is not always, and it is not with os_log), and assuming calls across the FFI boundary are infrequent (not a safe assumption at all).

Imagine you have some legitimate, useful debug-level logging you need to see happening in your Rust code you are calling.

Now imagine the FFI wrapper code you generated is also doing debug-level logging ... of a call that is happening 768,000 times per second (8 frequency bands x 96,000 samples per second).

Good luck reading that log.

Not to mention, there is measurable impact on performance of doing anything "near-zero cost" ... if you do it 768,000 times a second.

The Solution

It seems to me that unasked for, unremovable without forking logging is a bug, not a feature. I can totally understand wanting logging of FFI calls sometimes. The logging code should, IMHO, be off-by-default but enablable with a feature flag.

Or, if that is likely to break existing code that expects it, at the very least, able to be completely excised with a feature flag.

@badboy
Copy link
Member

badboy commented Aug 29, 2024

These are about to become trace level, so at least some of the issues you report become less of a problem.
As a workaround right now you could add a filter. We do that over in Glean as well. This should even avoid the overhead of calling into the underlying log implementation, because filtering is done before that.

@mhammond
Copy link
Member

While @badboy has some great workarounds, I don't see any reason we wouldn't take a patch for a feature here. That might also dovetail into a future where people start asking how to use tracing or similar instead of log

timboudreau added a commit to timboudreau/uniffi-rs that referenced this issue Aug 29, 2024
Addresses mozilla#2224 - even disabled logging can have overhead depending with some backends, and
in very high frequency calls, generates unacceptable overhead and log-spam.
bendk pushed a commit to bendk/uniffi-rs that referenced this issue Oct 16, 2024
Instead we can use the `trace!` macro to log details about FFI calls. By
default, it's compiled out but the `ffi-trace` feature can be used to
enable it. These tracing printouts are only really useful for debugging
failures when writing scaffolding/bindings code.

Addresses mozilla#2224 - even disabled logging can have overhead depending with some backends, and
in very high frequency calls, generates unacceptable overhead and log-spam.
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

3 participants