There seems to be a memory leak in this package

[zhuscat]

Reproducible example

https://github.com/zhuscat/expo-test-healthkit-lib

Steps to reproduce

As shown in the image, first tap “Request HealthKit Permission” to authorize. After tapping “Fetch Workout Data” once, memory usage is about 200 MB (I have 490 workouts and 43 000+ heart-rate data points). Then I rapidly tap “Fetch Workout Data” and watch memory climb in Xcode. When it reaches 1 GB I stop tapping, wait until CPU usage drops to a low level, and continue observing; the memory never falls back to 200 MB.

Memory usage after first tap

Keep tap until memory usage achieve 1G

Stop tapping but memory usage never falls back to 200MB

[robertherber]

Thanks for digging into this @zhuscat.

The workouts are returned as WorkoutProxies (HybridObjects) and there could potentially be something in how this is handled that could be optimized, either in this library or in nitro-modules. It could also be how you're managing the returned objects in your implementation. It could also be that it takes longer time for the GC to clean this up. PRs are welcome :)

Any high-level thoughts on this @mrousavy?

[mrousavy]

Hey, as for Nitro Modules, in my tests there are no GC issues with Hybrid Objects.

GBs are a lot for a workout module - what does this carry? If it carries a lot of data, call dispose() from JS. And implement memoryPressure in native

[robertherber]

The workout objects are a bit heavy, they expose both follow up-methods like fetching workout routes but are also serializing all data (including metadata) on the HKWorkout objects. The reason for this is I feel this is the most ergonomic way to expose them.

@zhuscat Could you try disposing the WorkoutProxies when you're done with them and see if that rids you of the memory leak? It's probably a good idea to chunk the processing instead of working with all samples at once as well, but that is unrelated to the memory leak you're experiencing.

[mrousavy]

Then it sounds like a good use-case for HybridObjects.

But keep in mind if something has a lot of resources you must do two things;

• (library author) Implement memorySize: https://nitro.margelo.com/docs/hybrid-objects#memory-size-memorysize
• (library user) Call dispose() once you are done with the HybridObject. This is how it always works in GC'd languages (same as in Java)

[robertherber]

Thanks for the input!

For implementing calculation of the memory size - is this a good utility? Since this WorkoutProxy object has many properties it would be nice if we didn't have to specify every property individually as in the example (potentially missing when properties are added etc).

[mrousavy]

No, this measures only struct memory layout - Nitro already does that natively. You'd have to estimate the heap memory pressure of your WorkoutProxy. I am still a bit sceptical - does the WorkoutProxy really have that much heap memory allocated? Are you sure its not something else entirely?