Re: Relieving memory pressure

[Alex Zavatone via Cocoa-dev]

> On Jun 7, 2020, at 3:15 PM, Steve Christensen via Cocoa-dev 
>  wrote:
> 
> For slide shows that I’ve seen, they typically display each image for several 
> seconds at a time. If that’s the case, why can’t you just load the next image 
> from disk on a background queue while the current image is being displayed 
> and not have to worry about memory usage needed to cache multiple images? (I 
> am assuming that you’ll need to load each image once anyway.)

Yeah, that’s like the preloading I suggested on an earlier thread about loading 
screensaver images.  Then after an image has transitioned out of display, you 
can nil all references to it.  If you know the order of when images will be 
displayed and removed, you can even create a mechanism for loading what’s to 
come and removing what has disappeared.  Pre-calculate your display array, 
unload everything you don’t need anymore and preload everything that will be 
displayed next.  Just make sure you don’t unload anything that is used in the 
current or next display.

You’d have a previous list of images, a current list of images and a next list 
of images.

Just do some set operations to make sure you’re not unloading and loading the 
same image.  

For unloading, I’m referring to making the image reference count 0 and then 
nilling variables.  

So, you’d have this mechanism rolling along on a thread while you have another 
process for the display of the images.

How does that sound?  

> If caching is required—apologies if I missed the “why” in earlier 
> comments—then have you looked at NSCache? From the docs:
> 
> The NSCache class incorporates various auto-eviction policies, which ensure 
> that a cache doesn’t use too much of the system’s memory. If memory is needed 
> by other applications, these policies remove some items from the cache, 
> minimizing its memory footprint.
> 
> 
>> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev 
>>  wrote:
>> 
>> Good question.
>> 
>> Well, some users want to feed my app with image files of 100 MB, even up to 
>> 400 MB (mostly jpeg compressed).
>> Those images have resolutions of over 8k, sometimes over 10k.
>> 
>> The slideshow app needs to be able to zoom into those images with at least a 
>> factor 2x scaling.
>> 
>> So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
>> resolution maximum should be sufficient.
>> 
>> An 8k x 8k image needs at least 200 MB (1 byte per channel).
>> I don't know how CGImage stores the uncompressed images internally,
>> but my experience seems to indicate that it uses significantly more memory 
>> than that.
>> (maybe it uses two bytes per channel, or even floats, or there is some other 
>> aux data)
>> 
>>> What do you need a 1GB thumbnail for? There is no screen that can display 
>>> that. For a slideshow app you could scale your thumbnails at creation time 
>>> to the users biggest screen pixel size, don’t you think?
>>> 
>>> Christos Konidaris
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Jens Alfke via Cocoa-dev]

> On Jun 7, 2020, at 3:27 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> For large images, this "thumbnail" can well occupy 1 GB of RAM.

That seems excessive. Shouldn’t you shrink it down to the actual screen 
resolution first?

> My current approach is to calculate the amount of unused memory,
> whenever a new images is put in the cache, and if that is below 1.5 GB, I 
> reduce the size of the cache

Memory is a complicated thing in a modern OS. Memory as address space and 
memory as RAM have little to do with each other. Trying to estimate how much 
memory is free for you to use is fairly pointless unless you want to learn a 
lot about the kernel and VM.

Usually the best compromise is to allocate purgeable address space and use that 
for your caches. The kernel can then toss out that memory and reuse it for 
something else if space runs low. There are low-level C APIs for this, and I 
think some Cocoa ones too,,but it’s been a decade since I’ve used them so I 
don’t recall the details...

—Jens
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Gabriel Zachmann via Cocoa-dev]

Thanks a lot for your response.

> If that’s the case, why can’t you just load the next image from disk on a 
> background queue while 

That is what I'm doing, since loading the next image could take up to 9 seconds.

> the current image is being displayed and not have to worry about memory usage 
> needed to cache multiple images? (I am assuming that you’ll need to load each 
> image once anyway.)

Unless the user wants to see one of the previous images (i'm storing up to 12).
In that case, the app should be able to go back to the previous image 
instantaneously.

> 
> The NSCache class incorporates various auto-eviction policies, which ensure 
> that a cache doesn’t use too much of the system’s memory. If memory is needed 
> by other applications, these policies remove some items from the cache, 
> minimizing its memory footprint.

Sounds interesting! I'll check that out.




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Steve Christensen via Cocoa-dev]

For slide shows that I’ve seen, they typically display each image for several 
seconds at a time. If that’s the case, why can’t you just load the next image 
from disk on a background queue while the current image is being displayed and 
not have to worry about memory usage needed to cache multiple images? (I am 
assuming that you’ll need to load each image once anyway.)

If caching is required—apologies if I missed the “why” in earlier comments—then 
have you looked at NSCache? From the docs:

The NSCache class incorporates various auto-eviction policies, which ensure 
that a cache doesn’t use too much of the system’s memory. If memory is needed 
by other applications, these policies remove some items from the cache, 
minimizing its memory footprint.


> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Good question.
> 
> Well, some users want to feed my app with image files of 100 MB, even up to 
> 400 MB (mostly jpeg compressed).
> Those images have resolutions of over 8k, sometimes over 10k.
> 
> The slideshow app needs to be able to zoom into those images with at least a 
> factor 2x scaling.
> 
> So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
> resolution maximum should be sufficient.
> 
> An 8k x 8k image needs at least 200 MB (1 byte per channel).
> I don't know how CGImage stores the uncompressed images internally,
> but my experience seems to indicate that it uses significantly more memory 
> than that.
> (maybe it uses two bytes per channel, or even floats, or there is some other 
> aux data)
> 
>> What do you need a 1GB thumbnail for? There is no screen that can display 
>> that. For a slideshow app you could scale your thumbnails at creation time 
>> to the users biggest screen pixel size, don’t you think?
>> 
>> Christos Konidaris

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Gabriel Zachmann via Cocoa-dev]

Thanks a lot for the hints - I'll look into the different ideas.

Also thanks to Christos for his hints.

Best regards, Gabriel



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Gary L. Wade via Cocoa-dev]

The vast majority of data used by a CGImageRef for any sufficiently 
representable image is going to be its bitmap data (a 1x1 pixel image 
wouldn’t), and you can calculate that by using CGImageGetBytesPerRow and its 
neighbor APIs.  If I recall from your previous posts, you are showing very 
detailed scans of artwork.  I believe NASA has a similar conundrum with their 
telescope data; perhaps there’s some open source solutions there that might 
help with your particular needs?  Just a thought.  Another thing I’d consider 
(which I haven’t personally done) is looking at what Metal can provide; you 
might have to drop down to that level for your needs.  And it may be just as 
important if you have a system with multiple large-format screens with so much 
data.
--
Gary L. Wade
http://www.garywade.com/ 

> On Jun 7, 2020, at 5:31 AM, Gabriel Zachmann via Cocoa-dev 
>  wrote:
> 
> Good question.
> 
> Well, some users want to feed my app with image files of 100 MB, even up to 
> 400 MB (mostly jpeg compressed).
> Those images have resolutions of over 8k, sometimes over 10k.
> 
> The slideshow app needs to be able to zoom into those images with at least a 
> factor 2x scaling.
> 
> So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
> resolution maximum should be sufficient.
> 
> An 8k x 8k image needs at least 200 MB (1 byte per channel).
> I don't know how CGImage stores the uncompressed images internally,
> but my experience seems to indicate that it uses significantly more memory 
> than that.
> (maybe it uses two bytes per channel, or even floats, or there is some other 
> aux data)
> 
> 
>> 
>> What do you need a 1GB thumbnail for? There is no screen that can display 
>> that. For a slideshow app you could scale your thumbnails at creation time 
>> to the users biggest screen pixel size, don’t you think?
>> 
>> Christos Konidaris
>> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.com

___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Relieving memory pressure

[Gabriel Zachmann via Cocoa-dev]

Good question.

Well, some users want to feed my app with image files of 100 MB, even up to 400 
MB (mostly jpeg compressed).
Those images have resolutions of over 8k, sometimes over 10k.

The slideshow app needs to be able to zoom into those images with at least a 
factor 2x scaling.

So I figured that if someone has a 4k monitor, creating thumbnails with 8k 
resolution maximum should be sufficient.

An 8k x 8k image needs at least 200 MB (1 byte per channel).
I don't know how CGImage stores the uncompressed images internally,
but my experience seems to indicate that it uses significantly more memory than 
that.
(maybe it uses two bytes per channel, or even floats, or there is some other 
aux data)


> 
> What do you need a 1GB thumbnail for? There is no screen that can display 
> that. For a slideshow app you could scale your thumbnails at creation time to 
> the users biggest screen pixel size, don’t you think?
> 
> Christos Konidaris
> 



smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Relieving memory pressure

[Gabriel Zachmann via Cocoa-dev]

I am developing a slideshow app; one of its features is that it keeps a history 
of the last N images it has displayed. It keeps kind of a cache , where it 
stores, among other things, the image returned by 
CGImageSourceCreateThumbnailAtIndex(), because this is one of the expensive 
operations.
(You might remember, that this "thumbnail" is necessary so that all the image 
processing going on in the CGImage API is done at load time, not at the point 
when the CALayer is created.)

For large images, this "thumbnail" can well occupy 1 GB of RAM.

So, when many large images are shown, the app might well use 8 GB or more,
which creates heavy memory pressure (Activity Monitor), and causes heavy 
stuttering.

My current approach is to calculate the amount of unused memory,
whenever a new images is put in the cache, and if that is below 1.5 GB, I 
reduce the size of the cache, releasing the old images (CGImageRelease).

For computing the amount of unused memory, I use host_statistics64(),
and vmstat.free_count+vmstat.inactive_count
(vmstat is the struct filled by host_statistics64).

My approach seems to help, but 
I am still wondering what is your opinion: is that a good approach?
Is the way I calculate unused memory the best / most reliable one?

One reason for asking is that I don't completely understand the way macOS 
manages memory.
(There seems to be a lot of "magic" going on in the VM manager.)


All insights and hints will be appreciated .
Best regards, Gabriel




smime.p7s
Description: S/MIME cryptographic signature
___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com