getsentry
perf: Caching loaded symbols list
What is the impact to dynamic libraries loaded after the list is cached? What's the approach taken by sentry-native/android?
Is there a hook from the OS that triggers when a new dynamic library is loaded? That could be used to invalidate the cache. Without such hook having that data cached would mean possibly reporting the incorrect library list.
maybe there's something like Java JNI -> https://docs.oracle.com/javase/9/docs/specs/jni/invocation.html#jni_onload
We could add a cache here https://github.com/getsentry/sentry-cocoa/blob/055a5200ccd4bf9d27305f0d9574fbcc8e5900f0/Sources/Sentry/SentryDebugImageProvider.m#L39-L51
Worth pointing out that this is called for every capture call.
Before we do that, we should investigate how heavy the call to SentryDebugImageProvider is. Maybe it's very fast and the benefit of adding a cache is not worth it because cache invalidation could cause problems.
A simple caching strategy would be to cache debugMetaArray and invalidate the cache when the getImageCount changes.
Some quick research tells me it takes around 5 ms on a MacBook Air with M1, which is unacceptable. We should implement a cache.
Inside SentryCrash we call _dyld_image_count(). The docs state
_dyld_image_count() returns the current number of images mapped in by dyld. Note that using this count to iterate all images is not thread safe, because another thread may be adding or removing images during the iteration.
This means images can be removed, so the cache approach with the getImageCount might not be sufficient.
We could use _dyld_register_func_for_add_image and _dyld_register_func_for_remove_image to be notified when new images are added or removed o invalidate the cache. We already use the first function here https://github.com/getsentry/sentry-cocoa/blob/e47eea57ef97e9b1a949a230b74219587619c33f/Sources/SentryCrash/Recording/Tools/fishhook.c#L260
Doing this properly could fix https://github.com/getsentry/sentry-cocoa/issues/1892.
Blocked by https://github.com/getsentry/sentry-cocoa/issues/1892, see https://github.com/getsentry/sentry-cocoa/pull/1965#issuecomment-1237080465.
Please reopen https://github.com/getsentry/sentry-cocoa/pull/1965 when tackling this issue, as it has some helpful information.
We did not reopen #1965 because we took a different approach. This was closed by https://github.com/getsentry/sentry-cocoa/pull/2939
