1. Topics
  2. Reporting your app's memory usage while testing.

Reporting your app's memory usage while testing.

Alex Zavatone
 

For those who actually want to be able to monitor and log iOS app memory being used while running tests.

This is a method/function based off of some Quinn advice posted on the Apple Dev Forum.  I modified it to return readable output and updated it to Swift 4.1.  It’s been helpful tracking down excessive memory usage while solving our leaks and excess allocations.

This method actually matches what is listed in the Activity Monitor and in Xcode’s memory window while running our app in the Simulator.  Swift file enclosed.



And here’s how I use it within XCTest

    override func invokeTest() {
        let formattedPhysicalMemoryUsedBeforeTests = Memory.formattedMemoryFootprint()
       // let totalPhysicalMemoryUsedBeforeTests: Int = Int(exactly: Memory.memoryFootprint() ?? 0) ?? 0
       
        TestLog().write("####█████ Physical memory used before starting test: \(formattedPhysicalMemoryUsedBeforeTests)")
        TestLog().write("####█████ Test: \(self.name)")
        TestLog().write("––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––")
       
        print()
        super.invokeTest()
    }


And here’s some sample output (text bolded for emphasis.

2019-10-03 17:34:04.655  ####█████ Physical memory used before starting test: 490.4609375 MB
2019-10-03 17:34:04.655  ####█████ Test: -[UserViewsLegacyLoanOverview testShowLoanSelector]
2019-10-03 17:34:04.657  ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
2019-10-03 17:34:36.650  ####█████ Physical memory used before starting test: 500.41015625 MB
2019-10-03 17:34:36.650  ####█████ Test: -[UserViewsLegacyLoanOverview testShowsLenderExpenses]
2019-10-03 17:34:36.652  ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
2019-10-03 17:34:41.820  ####█████ Physical memory used before starting test: 498.359375 MB
2019-10-03 17:34:41.820  ####█████ Test: -[UserViewsLegacyLoanOverview testShowsNoLenderExpenses]
2019-10-03 17:34:41.822  ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––


On Oct 4, 2019, at 5:02 AM, Sak Wathanasin <sw@...> wrote:



On 3 Oct 2019, at 20:10, Jens Alfke <jens@...> wrote:



On Oct 3, 2019, at 4:46 AM, Jeremy Hughes via Groups.Io <moon.rabbit@...> wrote:

Apple’s support page (https://support.apple.com/en-gb/HT200553) suggests that it is still possible for an application to bring down the system:

Only if it triggers some kind of bug in the kernel or in a system-level framework. Bugs do exist.


3rd party KEXTs more likely to be the culprit; OSX kernel panics are thankfully rare these days.

What _is_ possible is for an OS bug to mess up or crash a shared system process like the WindowServer from a request made by an app. Or for a kernel bug to crash the OS inside a system call made by an app.

Or some kind of h/w issue in Alex's case trigeering a kernel bug? Maybe dead or dying video or system memory, disk? Does it only happen in a particular Mac or everywhere?

Are there any recent core dumps in /cores? Not sure if this dir is created by defaul these days - you may have to manually create it if you want to enable core dumps.

Sak


?
Memory.swift

1 - 1 of 1