You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
The memory is not released when using Sharp in Electron (Some Linux distributions) #4460
Adding sharp.cache(false) does not fix this problem.
What are the steps to reproduce?
git clone https://github.com/ollm/electron-sharp-memory.git
cd electron-sharp-memory
npm install
npm start
Currently, when using Sharp on some Linux distributions through Electron, memory is not being released. To try to fix this, I've tested using global.gc() or moving Sharp into node:worker_threads, but neither worked.
When running the same Sharp script directly in Node, memory usage grows to about 200-500 MB and then stabilizes, but inside Electron it keeps increasing without stopping.
Please see electron/electron#35241 for discussion from other frustrated Electron users and suggestions for using a build of Electron without the memory cage feature.
This still sounds like memory fragmentation, possibly there have also been changes in the way V8 releases memory back to the OS in more recent versions.
Electron exposes control over the underlying V8 engine via --js-flags.
The semi-space is for short-lived data and the old-space is for long-lived data.
--max-semi-space-size (max size of a semi-space (in MBytes), the new space consists of two semi-spaces)
type: size_t default: --max-semi-space-size=0
--max-old-space-size (max size of the old space (in Mbytes))
type: size_t default: --max-old-space-size=0
Thanks, I've tried these flags, but they don't make any difference.
In the end, I found a temporary solution while this problem exists, I'm running Sharp inside a node:child_process.fork. Although the memory issue still occurs, I can kill the process, and doing so frees the memory (unlike node:worker_threads, which I initially tried, where killing it does not free the memory). So, after processing every X images, the process is killed and a new one is started (currently, I keep 2 open to switch between them with minimal downtime).
I've updated the example app with a simple implementation of this, so anyone encountering the same problem can use it as a reference.
Activity
lovell commentedon Oct 3, 2025
This is probably due to https://www.electronjs.org/blog/v8-memory-cage and the increased memory fragmentation it brings.
Please see electron/electron#35241 for discussion from other frustrated Electron users and suggestions for using a build of Electron without the memory cage feature.
ollm commentedon Oct 3, 2025
Hi Lovell, thanks for your response!
I'm not sure if this is related to
Memory Cage, I have tested the sample app with Electronv20.3.12, and the problem persists.I also tested old Sharp
v33.5with the latest version of Electron, and the issue does not occur in this case on Ubuntu 24.04.3.lovell commentedon Oct 3, 2025
This still sounds like memory fragmentation, possibly there have also been changes in the way V8 releases memory back to the OS in more recent versions.
ollm commentedon Oct 4, 2025
Thanks for the insight! Is there anything I can do on my side to mitigate this in my Electron app?
lovell commentedon Oct 4, 2025
Electron exposes control over the underlying V8 engine via
--js-flags.The
semi-spaceis for short-lived data and theold-spaceis for long-lived data.ollm commentedon Oct 6, 2025
Thanks, I've tried these flags, but they don't make any difference.
In the end, I found a temporary solution while this problem exists, I'm running Sharp inside a
node:child_process.fork. Although the memory issue still occurs, I can kill the process, and doing so frees the memory (unlikenode:worker_threads, which I initially tried, where killing it does not free the memory). So, after processing every X images, the process is killed and a new one is started (currently, I keep 2 open to switch between them with minimal downtime).I've updated the example app with a simple implementation of this, so anyone encountering the same problem can use it as a reference.
ollm/electron-sharp-memory@c1f53ad
sharp-fork.jschild-fork.jsUsage:
Using
node:child_process.forkin the sample appVideograbacion.2025-10-06.11.25.00.mp4