Thinking about Memory: Converting UIImage to Data in Swift

How often do you convert a UIImage into a Data object? Seems like a relatively straight forward task, just use UIImageJPEGRepresentation and your done.

After doing this I started seeing memory spikes and leaks appear which got me thinking on how I can better profile different options for performing this conversion. If you want to follow along you can create your own Swift Playground using this gist.

Approaches

The first step was looking at the different ways you can convert a UIImage into Data. I settled on the following three approaches.

UIImageJPEGRepresentation

Out of all the options this is the most straightforward and widely used. If you look at the testing blocks later in the post you can see I’m simply inlined the UIImageJPEGRepresentation with the test suite compression ratio.

UIImageJPEGRepresentation(image, compressionRatio)

view raw UIImageJPEGRepresentation.swift hosted with ❤ by GitHub

UIImageJPEGRepresentation within an Autorelease Pool

Out of the box UIImageJPEGRepresentation provides everything we need. In some cases I’ve found it holds onto memory after execution. To determine if wrapping UIImageJPEGRepresentation in a autoreleasepool has any benefit I created the convenience method UIImageToDataJPEG2. This simply wraps UIImageJPEGRepresentation into a autoreleasepool closure as shown below. We later use UIImageToDataJPEG2 within our tests.

	func UIImageToDataJPEG2(image: UIImage, compressionRatio: CGFloat) -> Data? {
	return autoreleasepool(invoking: { () -> Data? in
	return UIImageJPEGRepresentation(image, compressionRatio)
	})
	}

view raw UIImageToDataJPEG2.swift hosted with ❤ by GitHub

Using the ImageIO Framework

The ImageIO framework gives us a lower level APIs for working with images. Typically ImageIO has better CPU performance than using UIKit and other approaches. NSHipster has a great article with details here. I was interested to see if there was a memory benefit as well. The below helper function wraps the ImageIO functions into an API similar to UIImageJPEGRepresentation. This makes testing much easier. Keep in mind you’ll need to have image orientation yourself. For this example we just use Top, Left. If you are implementing yourself you’ll want read the API documentation available here.

	func UIImageToDataIO(image: UIImage, compressionRatio: CGFloat, orientation: Int = 1) -> Data? {
	return autoreleasepool(invoking: { () -> Data in
	let data = NSMutableData()
	let options: NSDictionary = [
	kCGImagePropertyOrientation: orientation,
	kCGImagePropertyHasAlpha: true,
	kCGImageDestinationLossyCompressionQuality: compressionRatio
	]

	let imageDestinationRef = CGImageDestinationCreateWithData(data as CFMutableData, kUTTypeJPEG, 1, nil)!
	CGImageDestinationAddImage(imageDestinationRef, image.cgImage!, options)
	CGImageDestinationFinalize(imageDestinationRef)
	return data as Data
	})
	}

view raw UIImageToDataIO.swift hosted with ❤ by GitHub

What about UIImagePNGRepresentation?

UIImagePNGRepresentation is great when you need the highest quality image. The side effect of this is it has a largest Data size and memory footprint. This disqualified UIImagePNGRepresentation as an option for these tests.

Testing Scenarios

For my scenarios it was important to understand how memory is impacted based on the following:

Number of executions, i.e. what is the memory impact for calling an approach on one or many images.
How the Compression ratio impacts memory usage.

Image quality is an important aspect of my projects, so the tests where performed using the compression ratios of 1.0 and 0.9. These compression ratios where then run using 1, 2, 14, 20, and 50 executions. These frequencies demonstrate when image caching and Autorelease Pool strategies start to impact results.

Testing Each Approach

I test each of the above mentioned approaches using the template outlined below. See the gist of the details for each approach.

At the top of the method a memory sample is taken
The helper method for converting a UIImage to a Data object is called in a loop.
To make sure we are measure the same resulting data across tests, we record the length of the first Data conversion.
When the loop has completed the proper number of iterations the memory is again sampled and the delta is recorded.

There is some variability on how each approach is tested.

The implementation for each approach is slightly different, but the same iteration and compression ratios are used to keep the outcome as comparative as possible. Below is an example the strategy used to test the JPEGRepresentation with Autorelease Pool approach.

	func Test_JPEGRepresentation_AutoRelease(iterations: Int, compressionRatio: CGFloat,image: UIImage) {
	//Gather the initial information
	let startReading = report_memory()
	print("Memory at start: \(startReading / 1024 / 1024) mb")

	//Loop through the number of test iterations specified
	for index in 1...iterations {
	if let data = UIImageToDataJPEG2(image: image, compressionRatio: compressionRatio) {
	//Sample the length of the first result to make sure we are comparing the same size
	if index == 1 {
	//Report out results
	let dataSize = Int(data.count / 1024 / 1024)
	print("Data Length: \(dataSize) mb")
	}
	}
	}

	let endReading = report_memory()
	print("Memory at finish: \(Int(endReading / 1024 / 1024)) mb")
	let delta = (Int(Int(endReading) - Int(startReading)) / 1024 / 1024)
	print("Memory delta: \(delta) mb")
	}

view raw Test_JPEGRepresentation_AutoRelease.swift hosted with ❤ by GitHub

Test Results

Below is the result broken down by iteration.

Results for 1 Iteration

uiimagetodata-1

Results for 2 Iterations

uiimagetodata-2

Results for 14 Iterations

Results for 20 Iterations

Results for 50 Iterations

uiimagetodata-50

Conclusion

I am sure there is a ton of optimizations that could be made to bring these numbers down. Overall the usage of UIImageJPEGRepresentation wrapped within an Autorelease Pool looks to be the best approach. There is more work to be done on why the compression ratio has an inconsistent impact, my guess is this is a result to caching within the test.

Although the ImageIO strategy was better in a single execution scenario I question if the proper handling of image orientation would reduce or eliminate any of your memory savings.

Caveats

There are more comprehensive approaches out there. This is just an experiment using Playgrounds and basic memory sampling. It doesn’t take into account any memory spikes that happen outside of the two sampling points or any considerations around CPU utilization.