search

bitdriftlabs / capture-sdk

mobile bitdrift SDK
Other
9 stars 2 forks source link

Support real lazy evaluation of the log message lambda #60

Open murki opened 3 days ago

murki commented 3 days ago

Two potential improvements to the logging interface which currently accepts a message: () -> String lambda:

  1. Reduce the number of memory allocations. The way it is today the code will allocate once for the lambda, and then again for the string. The ideal way to solve this would be to use inline in the method but since we use interfaces in between that's currently not possible. We should at least provide an overload that just takes the String directly for cases where the consumers know there won't be any string interpolation.
  2. Accepting the lambda can give the idea to consumers that the code would be conditionally executed based on the matcher rules. Since we put every log in the ring buffer we should at least add documentation around the expectations on the execution of this lambda. The only times the lambda wouldn't be executed is if the SDK is not initialized.
pyricau commented 2 days ago

This is very much a blocking point for us.

We would need the ability to send all of our logcat {} (same as Timber) logs to bitdrift, with the assurance that the strings aren't even evaluated by default / the lambdas don't run, because that can have a significant performance impact. So based on some tag and server side rule we'd want to conditionally evaluate.

The lambda approach is actually inlined syntactic sugar on 2 basic API building blocks: 1) "should I evaluate this log?" and 2) "here's my log"

pyricau commented 2 days ago

Once that top level API is available, we would benefit even from a new API that doesn't take a string but an Okio Source instead (similar to Java InputStream), so that we could serialize some event classes directly to a json string stored in the ring buffer without creating temporary strings per log.

Although thinking about this more, this might not work because you require knowing the log size when allocating an entry in the ring buffer. so, that might be a bad idea, or might need an API that includes the size.