hi there, we are using `coil` `3.0.0-alpha06` see...

# multiplatform

[Suresh Maidaragi]

hi there, we are using coil 3.0.0-alpha06

seeing sudden spike in memory consumption around ~180MB, in case of iOS platform when we try to get bitmap using coil3, the size of

this image▾

post download is around 1.7MB. but we are not sure why is it giving memory spike of ~180MB, can someone help to know what is that causing the memory spike

@OptIn(ExperimentalCoilApi::class)
suspend fun getBitmap(url: String, context: PlatformContext): Bitmap? {

    return coil3.ImageLoader.Builder(context).diskCachePolicy(CachePolicy.ENABLED).networkCachePolicy(CachePolicy.DISABLED).build().execute(coil3.request.ImageRequest.Builder(context).
        data(url)
        .build()).image?.toBitmap()

}

when we load image of size just in KB's it not giving memory consumption spike.

[Sergey Y.]

When you load an image file, such as a JPEG, into memory, the file itself is a compressed container designed to save space. For example, a 1.7 MB JPEG is a compressed representation of the actual image. This compression is lossy, meaning it reduces file size at the expense of some data loss, which is why the file can be relatively small.

Upon loading, the system decodes the image to display the actual picture. The decoded image is significantly larger because it is now uncompressed. In memory, each pixel requires more space. The image you provided has dimensions of 6,000 by 4,000 pixels, totaling 24 million pixels. Most decoders utilize the RGBA8888 format, allocating 4 bytes per pixel — one byte(8bit) for each of the red, green, blue, and alpha channels.

Consequently, the memory requirement is calculated as:
24,000,000 pixels * 4 bytes per pixel = 96,000,000 bytes, or 96 MB.

However, additional factors such as system memory management overhead and extra buffers, which may arise from necessary or redundant copying, can inflate this figure to approximately 180 MB. This accounts for the observed spike in memory usage when the image is loaded.

In summary, your 1.7 MB file acts as a container—akin to video formats like MP4 or MKV — that stores image data compressed via lossy compression. Once loaded, this data is expanded into a 1D memory array sized at width*height. In the context of Android development, this may be represented by an IntArray, with each element encapsulating 4 channels of unsigned bytes packed into a single integer using bit masking. The representation remains very similar for other platforms. This array is then processed by the rendering system to display the image. 🙂

[Sergey Y.]

This is completely normal to see such memory consumption if you load an image of this size. If you want to save some memory, you need to load a downscaled version of the image. I believe Coil has configurations to load a downsampled version of the image, rather than decoding it to the full resolution.

[diegopap]

Probably because it is using cellular data 😂

[jw]

You also seem to be creating a new image loader for each image load. Do not do this. Make it once, and share it.

[Suresh Maidaragi]

I mean device ram consumption on iphone

[Suresh Maidaragi]

Jake Wharton [5:06 AM]

You also seem to be creating a new image loader for each image load. Do not do this. Make it once, and share it

We tried but still we see spike. This issue happens only on iOS. is something seiko doing in background.

[Suresh Maidaragi]

@Sergey Y. Thanks for in detailed response, we tried setting FilterQuality to LOW in case of coil still no luck.

[Sergey Y.]

FilterQuality is not about scaling

[Suresh Maidaragi]

Right later tried to set size and precision it reduced to 140mb

[Sergey Y.]

Ideally, the image size should not be larger than the view size it is displayed in.

[Suresh Maidaragi]

This image spike is going to be huge concerns when image is of >5MB

[Suresh Maidaragi]

if we have 50+ images in single lazycolumn, it would results in OMM in case of ipad 9th Gen etc

[Sergey Y.]

File size matters less than decoding parameters. If all your URLs lead to high-resolution images, consider providing a lower-resolution alternative for preview purposes if the server is under your control. If it is a third-party service, check if they support configurable image resizing during requests. If no option is available, avoid decoding images to high resolution for items like lists and icons.

[Suresh Maidaragi]

what is the recommended size in this use case Serhii?

[Suresh Maidaragi]

generally we wanted to support to ipad and iphone

[Sergey Y.]

> Ideally, the image size should not be larger than the view size it is displayed in.
>
if you're asking about decoding options.

[Suresh Maidaragi]

When we are done using the image loading and usage, and move back to previous screen, why it is not completely releasing the consumed memory, @Sergey Y. any suggestions to release retained memory.

ex : If an image consumed ~150MB and when we move back it retaining around ~60MB, why this 60MB not clearing ?

[Sergey Y.]

I’m not familiar with iOS memory management in detail, but if the memory is not freed up after you leave the screen, you might be experiencing a memory leak. However, I do know that Xcode has a powerful memory analyzer that can help resolve these issues. Sorry I can't be more specific, as I’m not an iOS developer. 🤷‍♂️

[Suresh Maidaragi]

we checked on iOS profile instruments, we dont see memory leaks at all.