Discrepancy between Xcode Memory Report and Xcode Instruments Memory Profiler

Question

Will_InHaus OP

Created 2w

Replies 2

Boosts 0

Participants 2

Hi Apple Engineers,

I am encountering an issue where the memory usage reported by the Xcode memory report and the Xcode Instruments memory profiler are not aligned. Specifically:

Xcode Memory Report:

After implementing autoreleasepool, URLSession reading a zip file, and moving the task inside DispatchQueue.global().async, the memory usage goes down from 900MB to 450MB, indicating a potential memory leak.

Xcode Memory Report copy.png

Xcode Instruments Memory Profiler:

The memory usage goes down from 900MB to 100MB, suggesting that the memory has been properly released and there is no significant memory leak.

Instrument Memory Leak Trace copy.png

Could you please help me understand the discrepancy between these two tools and provide guidance on the appropriate way to interpret the memory usage in my application? Which result I should rely on it?

I would greatly appreciate your insights and expertise on this matter. Thank you in advance for your assistance.

Boost

Answer 1

Will_InHaus OP

1w

Hi Apple Engineer,

Is there anything missing I can provide for your response?

0

Answer 2

Developer Tools Engineer OP

Apple

1w

Thanks for reaching out!

The Xcode memory report displays your app's footprint (the size of all dirty + swapped and/or compressed memory). The Allocations instrument reports the total logical size of active heap allocations and virtual memory regions. These can be different - for example, it's possible for your heap to have a high footprint even if there are few active heap allocations if the heap is highly fragmented (where heap allocations are spread out over many pages, dirtying extra memory). This is discussed a bit in the beginning of the "Analyze heap memory" WWDC '24 presentation.

It's also possible that you're observing your app behaving differently when running with Xcode and Instruments because your app is built in different configurations. By default the Xcode Run action uses a debug build of your app, and the Profile action (activated with the menu item "Product -> Profile") uses a release build. You may see more similar reports from the Xcode memory report and Allocations instrument if you use the same configuration for both. You can change these via "Build Configuration" in your project's scheme settings for the Run and Profile actions (https://developer.apple.com/documentation/xcode/customizing-the-build-schemes-for-a-project/#Configure-the-runtime-environment-for-built-products).

If you still see significant differences between the Xcode memory report and Allocations instrument after confirming that both are analyzing the same build configuration, you can use tools like the VM Tracker instrument to better understand and reduce your app's footprint. VM Tracker can be configured to snapshot information about all of your app's virtual memory periodically as it runs. This includes the sizes of the app's dirty and swapped or compressed memory, which makes up the app's footprint (the metric displayed by the Xcode memory report). "iOS Memory Deep Dive" from WWDC '18 discusses diagnosing footprint issues in depth.

0