Tracking IOKit Dirty Memory in iOS using Instruments

I’ve been spending the past week of Loose Leaf development tracking where and how my app’s memory is allocated at run time. My goal is to send all of my memory stats to MixPanel with every event I track. During beta and after launch, all of this information will help me to better understand how people are using the app.

LooseLeaf Runtime Memory

This’ll be especially helpful if/when I get memory crash reports – tracking down which iPad models are having the hardest time, and being able to use MixPanel to see how Loose Leaf is allocating memory on those iPad models – is it OpenGL textures? Vertex buffers? UIImages? Core Animation?

Knowing how the app’s caches are performing, where memory is allocated, and why it’s allocated is going to be a huge help to further optimize performance after launch.

My end goal is to have similar memory allocation numbers at runtime that the Allocations tool in Instruments gives me when profiling. So far, I have the following debug screenshot that shows how and where memory is allocated in the app. The important numbers from the screenshot are the 28.6Mb of memory in the MMLoadImageCache (these are UIImages), and the 101Mb in the MMPageCacheManager (this is largely OpenGL, including the Textures and VBOs later in the screenshot). These sum to roughly 130Mb of actively allocated and used memory.

I also have a few views that rely on drawRect:, and those views have their backing store created by Core Graphics. All this together can account for the 167Mb of memory that Instruments shows me in the Allocations instrument.

Screen Shot 2014-05-31 at 2.07.29 PM

What’s going on with that 392 Mb of dirty memory?! Yikes, this number is over double my allocations and is absolutely terrifying. After some research, I found this post about Finding iOS Memory, which mentions that OpenGL’s textures are shown Dirty memory labelled as IOKit. Sure enough, i see lots of IOKit memory when I look at dirty memory:

Screen Shot 2014-05-31 at 2.24.23 PM

This makes me worry that perhaps I’m not cleaning up old textures properly, and I’m somehow leaving my memory allocated in OpenGL after I’m finished with a texture. Looking through my code, I’ve confirmed I’m calling “glDeleteTextures(1, &textureID);” for my texture IDs like I should – so what could the problem be?

Then I found this answer on StackExchange, which mentions:

Some drivers may keep the storage allocated so that they can reuse it for satisfying future allocations (rather than having to allocate new storage – a common misunderstanding this behaviour leads to is people thinking they have a memory leak), other drivers may not.

If that’s true, then that’d mean that I have done my job and properly released that memory, and OpenGL is just optimizing when it actually frees that memory back to the system.

Screen Shot 2014-05-31 at 2.31.17 PM

To test this out, i background my application and open up Pages, Keynote, and Numbers in an attempt to force a Low Memory Warning on the system. Instruments shows these memory events being triggered while my app is in the background, and more importantly it shows the dirty memory falling back into line with my current allocations. When I return to my app after opening a few apps and browsing around outside my app, Instruments now shows dirty memory much closer to my current allocations:

Moral of the story: Keep a close eye on allocations and dirty memory, and make sure you know why and when your memory is marked as dirty. It turned out that Loose Leaf is doing a good job cleaning up its old unused OpenGL textures, but OpenGL is just slow when it deallocs that memory. I may try to do a better job loading new textures into old texture’s memory and purposefully re-using memory instead of always allocating new, but I’m glad to see that I didn’t have a massive leak after all.

Providence Cancer Center: $1M Matching Donations Challenge

Over the past 5 years, we have been extremely blessed with Christi’s good health after being diagnosed with brain cancer. Five years ago, Dr. Gore at Providence hospital saved Christi’s life over the course of 3 brain surgeries. We decided to donate her tumor to the research at Providence, and it’s been used (along with many other tumors and lots of research) to help create a vaccine for brain cancer. It’s absolutely incredible work they’re doing there, and it’s excited to get updates about the research from time to time.

Just recently, we received a note from Providence that an anonymous couple has pledged to match all donations up to $1M as long as the donation is pledged (not paid) by May 20th. It only needs to be paid to Providence by Dec 31st, 2016. More info from the email that Shari Scales sent me last week:

As promised, I’m following up with the details about a generous Matching Gift Challenge offered to us. Between March 22 and May 20, they are matching $1 for $1 ALL gifts and pledges to our cancer programs. Pledges (written intentions to make a gift) can be fulfilled over time on a schedule that is convenient for our donors. Pledges simply need to be paid in full by December 31, 2016 to qualify for the match. This time period can give donors many options to consider, including, for example, making 3 year-end gifts, 6 half-yearly gifts, monthly gifts, on whatever schedule works.

The nice thing about this match is that it’s not an “all or nothing” deal. It’s truly one dollar raised, one dollar earned. That means, every gift counts no matter the size, and every gift DOUBLES no matter the size. I have attached information about the Challenge as well as a pledge form, and will mail all of these things to you as well, along with a couple of articles that I mentioned last night.

The research they’re doing at Providence is absolutely incredible. This vaccine essentially teaches your immune system to recognize cancer cells for what they are, dramatically increasing the effectiveness of other treatments and helping your body fight off the cancer itself. It’s extremely exciting stuff, and we’re honored to be a part.

If you’d like to make a donation, that’d be matched and doubled, you can download the PDF form here. If you’d like your donation to be earmarked specifically for the vaccine research, you can designate it to: “Drs. Bahjat, Crittenden, and Gore – Glioblastoma Multiforme Vaccine” on the form.

Challenge Donation Form

Loose Leaf – A Different Kind Of Paper

I’m extremely excited to show you the first demo of my new scratch paper app Loose Leaf!

This app has been my labor of love for nearly two years, and I’m finally getting close to the App Store release this summer. (Sign up to be notified when it’s ready if you haven’t already!) All of the major development is done, and I’m now working through the last few features and testing.

So what is Loose Leaf?

It’s just that: scratch paper. The vast majority of my notes and sketches don’t need to be perfect. It’s far more important that I get them down quickly than it is to get them down perfectly. When I’m in a meeting, or when an idea hits me, I don’t want to lose the flow of conversation or forget any details while I’m sorting into the right notebook or picking just the right shape for my diagram.

Loose Leaf lets you quickly and easily jot down a note, diagram, idea, photo, mockup, or annotation, then show it in the moment, and 1 button export it if you need to save it. No settings. No Sync. No menus. No textures. No brush arsenal. No popovers. No “edit mode” vs “pen mode” vs “image mode”. No fluff.

It’s just blank paper, simple gestures, and simple tools. You can write on it. You can throw some pictures on it. You can use scissors to cut it up. You can export when you care. And that’s it. And all of it just works like you think it should: a pen, an eraser, a ruler, some scissors, images, and blank paper.

Available this Summer

I’m finishing up the very last features and testing, and will be launching on the App Store this summer. Sign up and get notified when it’s live.

Google Author link
Page 6 of 46« First...45678...203040...Last »