Increase JavaScript Heap Memory in Electron Renderer Process - google-chrome

My Electron application needs a huge amount of memory in the renderer process. Yes, that's intended and no, there's no way around it. (At least none that would make any sense.)
Using performance.memory in the renderer process gives: jsHeapSizeLimit: 3760000000. And I can indeed allocate memory up to about 3.5 GB, then the process will crash.
Now, there's the --max-old-space-size command line parameter to control the available JS heap size of the renderer process in an Electron app. I set it in main.js like this:
app.commandLine.appendSwitch('js-flags', '--max-old-space-size=1024')
Using performance.memory now shows: jsHeapSizeLimit: 1130000000, which is just a little bit more than 1GB, so decreasing the JS heap size works. But I cannot increase it to more than the 3,760,000,000 bytes.
Trying to set it to 8 GB doesn't increase the JS heap size limit:
app.commandLine.appendSwitch('js-flags', '--max-old-space-size=8192')
performance.memory still says: jsHeapSizeLimit: 3760000000
What am I missing? Is max-old-space-size only able to reduce available memory and not to increase it? Or do I have to set another parameter so that the renderer process can utilize the available old space?
The important parts of process.versions:
{
node: '14.16.0',
v8: '8.9.255.24-electron.0',
electron: '12.0.4',
chrome: '89.0.4389.114'
}
This happens on my Macbook with 16GB as well as on my Windows desktop with 64 GB.

I hope you found the answer to your question.
However there is this Github thread that gave an answer :
https://github.com/electron/electron/issues/2056
What work for me (electron 11.5.0) is to add --js-flags=--max-old-space-size=8192 in the packge.json script :
{
"scripts": {
"start": "electron --js-flags=--max-old-space-size=8192 main.js"
}
}

Related

Three.js freezes Chrome completely, huge texture in GLTF model

I want to load a ludicrous, binary glTF object with only a few polygons (~250), and a huge texture of size 10,000 x 5,500 pixels. The file is "only" 20MB in size.
When I load it using Three.js, Chrome hangs in its entirety for nearly 15 seconds. When looking in the profiler, pretty much nothing is going on during the freezing time.
If you want to load the file yourself, you can download it at https://phychi.com/uni/threejs/models/freezing-monster.glb, and the whole scene can be visited at https://phychi.com/uni/threejs/ (until I've found a solution or given up).
The behavior stays the same, whether I call GLTFLoader.load(), GLTFLoader.loadAsync(), or create my own Promise, and call .then(addToScene), without any awaits.
Does somebody have a magical solution? Or if not, how could I profile it more efficiently, seeing the internal calls? Or should I just open a bug report for Chrome/Three.js?
PS: Windows 10 Personal, Ryzen 5 2600, 32 GB RAM, RX 580 8GB.
The issue should be resolved by upgrading the library to r135(the current release).
The releases r133 and r134 have a change that introduced a performance regression on Windows when using sRGB encoded textures.

View the contents of memory footprint of a chrome tab

I've got a memory problem in my application. Symptoms are weird: js heap stays stable at around 30 mb, while memory footprint of a browser tab is growing over time out of bounds and eventually crashes entire mac os (I'm looking at memory footprint numbers provided by chrome's task manager). It takes several hours and I can reproduce it consistently. As heap review doesn't give me any clues at all, I'd like to examine the memory allocations for the browser tab, where my application is running. Does chrome provide any tools for that?

Memory leak in Task Manager even if Chrome Heap Snapshot shows zero delta

I am investigating a JS memory leak issue using Chrome DevTools. Using heap snapshots and doing comparison, I was able to root cause the component responsible for leaking the memory.
Problem I am seeing is that after the fix, even if Chrome DevTools shows no leak, Windows Task Manager shows increase in memory with usage.
Below are the heap snapshots of before and after fix.
Before fix:
After fix:
Am I missing anything here? Is Chrome DevTools somehow showing wrong result?
I read a similar thread here. But it isn't of much help.

Chrome memory measurement now almost flat for longer test runs

In order to check our web application for memory leaks, I run a machine which does the following:
it runs automated End-to-End tests over (almost) the entire application in Chrome
after each block of tests, it goes to a state of the web application where almost nothing happens
it triggers gc(); for garbage collection
it saves totalJSHeapSize, and usedJSHeapSize to a file
it plots out the results for each test run to a graph
That way, we can see how much the memory increases and which are the problematic parts of our application: At some point the memory increases, at some point it decreases.
Till yesterday, it looked like this:
Bright red (upper line): totalJSHeapSize, light red (lower line): usedJSHeapSize
Yesterday, I updated Chrome to version 69. And now the chart looks quite different:
The start and end amount of memory used (usedJSHeapSize) is almost the same. But as you can clearly see, the way it changes over the course of the test (ca. 1,5h) is quite different.
My questions are now:
Is this a change in reality or in measurement? I.e. did Chrome change its memory handling? Or just the way it puts out memory values via totalJSHeapSize, and usedJSHeapSize?
Concerning memory leaks, is it good news or bad news for me? Like: Before I had dozens of spots where memory increases, now I have just three. Is this true? Or are the memory leaks in the now flat areas still there and hidden?
I'm also thankful for any background information on how Chrome changed its memory measurement.
Some additional info:
The VM runs under KUbuntu 18.04
It's a single web page application done with AngularJS 1.6
The outcome of the memory measurement is quite stable - both before and after the update of Chrome
EDIT:
It seems this was a bug of Chrome version 69. At least, with an update to Chrome 70, this strange behavior is gone and everything looks almost as before.
I don't think you should be worry about it. This can happen due to the memory manager used inside the chrome. You didn't mentioned the version of your first memory graph, possibility that the memory manager used between these two version is different. Chrome was using the TCMalloc which take the large chunk of memory from the OS and manage it, once the memory shortage happenned with TCMalloc then it ask again a big chunk of memory from OS and start managing it. So the later graph what you are seeing have less up and downs (but bigger then previous one) due to that. Hope it answered your query.
As you mentioned that
The outcome of the memory measurement is quite stable - both before and after the update of Chrome
You don't need to really worry about it, the way previously chrome was allocating memory and how it does with new version is different(possible different memory manager) that's it.

Chrome garbage collector going crazy

Using Version 48.0.2564.109 m.
We have a javascript web app (built with ExtJS). In Chrome, when we leave our app sitting there for a while, the GC starts going nuts. In Task Manager, you can see the CPU constantly spinning around 25%.
I took timeline snapshots and CPU profiles, and you can see the GC, about 10 times a seconds, try to collect memory, but collects 0B.
Our app is a large enterprise application and does use quite a bit of memory and updates the screen periodically.
But, there is absolutely no javascript code running during this time. So I can't see that it is something our app is actively doing
Does anyone know what could be triggering this?
It is killing performance of our app.
Also, it only happens when our tab is active. If you switch to a different tab, the CPU dies down and the GC stops.
Is there other data I need to collect to help determine this?
What is your app current JS heap size? You can check it by collecting timeline and enabling memory check box.
It looks like your app is close to the V8 memory limit, so V8 is trying to free some memory. If it is expected for the app to use that much memory, you can increase the limit on your host with something like: --js-flags="--max-old-space-size=2048"
Otherwise it might be just a memory leak in your code. Use heap profiler to hunt it down.