[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#61763: 30.0.50; Image Cache Size growth
From: |
Manuel Giraud |
Subject: |
bug#61763: 30.0.50; Image Cache Size growth |
Date: |
Sat, 25 Feb 2023 13:19:20 +0100 |
Eli Zaretskii <eliz@gnu.org> writes:
[...]
>> Maybe we should have parameter (maybe a custom) that limit this
>> growth up to a certain point and then start uncaching older images.
>> WDYT?
>
> We cannot uncache an image that is being displayed in some window.
> Doing so would immediately cause a crash on the next redisplay cycle.
> So lowering the eviction delay is the mechanism you should use,
> assuming it helps in your use case. Did you try that, and if you did,
> did it help? For how much time do you display each image before you
> discard its buffer or delete its window?
I've try with image-cache-eviction-delay at 30 seconds and I never
exceed 700MiB as Image Cache and never hit a "Memory exhausted". So
this is solved for this use case. Thanks for your patience Eli!
--
Manuel Giraud
- bug#61763: 30.0.50; Image Cache Size growth, Manuel Giraud, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Eli Zaretskii, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Manuel Giraud, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Eli Zaretskii, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Manuel Giraud, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Eli Zaretskii, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Manuel Giraud, 2023/02/24
- bug#61763: 30.0.50; Image Cache Size growth, Eli Zaretskii, 2023/02/25
- bug#61763: 30.0.50; Image Cache Size growth,
Manuel Giraud <=
- bug#61763: 30.0.50; Image Cache Size growth, Eli Zaretskii, 2023/02/25