The maximum amount of memory that can be handled by a browser is different.
In Canvas, which is often used in browser games to take advantage of the graphic performance, there seems to be a specific memory limit available, so you need to be careful. I'd like to verify that separately.
The actual way to check is to create a 0.5 M (500,000) string and pack it as an associative array in a global variable with a unique key to see how far you can pack it in.
A string made up of a sequence of 0.5 M (500,000) digits would require 1 Mbyte of space inside the browser in Unicode UTF-16.
How many strings of 1MBtyte can be stored in the memory limit?
Please note that this is just a guideline.
The specs of the devices I measured are as follows.
Here is the source code that I made by measurement. Save the following as html, open it in your browser, and press the "Start calc" button. The measurement can be started.
If you want to run it in your own environment, copy the above and save it locally as an html file and load it in your browser.
attention You can also use it in the same way as a regular browser. I think that there is not so much that an evil influence involving the OS is running, but be careful just in case.
The latest version of Google Chrome (desktop 64-bit version), ver 80.0, can handle up to 4GB of memory per tab as of April 2020.
original story See the V8 engine specification and the Chromium forum. I've included a link in the reference section at the bottom of the page.
Paused before potential out-of-memory crash and the exception The log was output to the console and stopped when it detected a step before the forced termination.
![Stop Chrome before memory crash] (. /chrome_before_outofmemory_crash.png)
The memory capacity of my PC was still sufficient, but when I was processing images in a crunchy way, I had to use the You may need to be careful.
After allocating about 1.6 GB of memory, the browser crashed and restarted, and Out of Memory exception detection doesn't seem to be possible.
As of April 2020, Internet Explorer 11 is too old to use but is still being used in systems and web services in public offices in specific country like Japan, accounting for about 5-10% of all Internet access in Japan. (*Survey by StatCounter and others] (https://gs.statcounter.com/browser-market-share/all/japan/#monthly-202001-202007))
The reality is that IE11 is rarely used and web services are created based on Edge and Chrome.
How long will web apps support IE11? Until Microsoft completely drops support for IE11, it will continue to be used as a web service and usage browser until 2025-2027 or so, for reasons such as accessibility and maintenance on older devices.
The Edge browser is getting a major update on January 15, 2020, changing the browser's engine from Microsoft's own EdgeHTML to Chromium, an open source browser published by Google.
It was updated to a Chromium-using version from April 2020 via the Windows Update in Japan. So for future web apps that we publish on the Internet, we don't need to worry about the results of the Edge browser using this old EdgeHTML engine so much, it's just a reference for the excessive period.
As a result, the browser crashed and restarted after about 3.8 GB. The image was captured before the crash.
Note that the Edge browser, which uses the EdgeHTML engine, looks like the image name of the process used for browser rendering is "MicrosoftEdgeCP.exe", but from Chromium it's a different process name, so be careful when monitoring tasks.
The Edge Chromimum version crashed when it was able to allocate up to 0.8 GB of buffer space. It seems that the process is able to allocate up to 2.23 GB, which is numerically the same as the Chrome version. In the Chromium version, the image name of the process is changed to "msedge.exe".
I don't have MacOS or iPhone on my device, and Apple has only released Safari for Windows up to version 5.17 in 2012, so I don't want to measure it. I'd like to update the information when I have a chance to measure it on Mac OS.
I will update the information when I have a chance to measure it on Mac OS.
I checked with the latest version 75.0 (64 bit) on April 15, 2020. On the screen, after allocating a buffer of about 1.4 GB, the browser crashed and became unresponsive.
In fact, when I checked the amount of memory used by the Firefox process, it crashed using up to about 4.3 GB.
Presumably, the reason is that the source strings created in the course of the string merging process are pooled like a StringBuffer and continue to be used, and are not subject to being released from memory space.
It may be simply because Firefox's garbage collection has not been activated to free the unwanted memory.
string pool I think the problem is that internally pooled strings continue to be possessed because of the increase or decrease in the size of the buffer allocations when the string join part is tweaked.
It crashed with a buffer area of about 400MB. In fact, I was able to allocate about 1.1 GByte as a Chrome app process in Android, and the You won't be able to grab it with a try-catch, but you'll see a crash screen like this
The results were exactly the same as the desktop version. Please refer to the desktop version.
I think the string concatenation and pooling process varies from browser to browser, so there is a difference between the apparent size of the allocated memory and the actual available memory area.
The difference between "size allocated by the buffer" and "memory allocated by the process" is so large that the result is a bit subtle, but modern browsers seem to be able to allocate memory in GBs without problems.
You need to be careful about memory leak, but you don't need to allocate memory by paying attention to the upper limit every time you allocate memory, and make frequently to be able to release it.
|browser||string length of allocated buffer||memory allocated by process|
|Google Chrome Ver 81.0
Desktop 64bit version
|0.8 GB||2.3 GB|
|Internet Explorer 11
Desktop 32bit version
|0.45 GB||1.6 GB|
|Old Edge Ver 44.0
EdgeHTML Desktop 64bit version
|2.8 GB||3.6 GB|
|Edge Ver 81.0
Chromium Desktop 64bit version
|0.8 GB||2.3 GB|
|Firefox Ver 75.0
Desktop 64bit version
|1.4 GB||4.3 GB|
|Google Chrome Ver 81.0
|0.4 GB||1.1 GB|
|Firefox Ver 68.7
|1.4 GB||3.5 GB|
Thank you for your message.
Sorry. The Error has occurred.We apologize for the inconvenience.Please try again in a few minutes or contact us via DM below.Twitter:@NodachiSoft_engName:
Send the following information to us. If you are happy with your submission, please click "Send". If you want to modify it, please click "Back".Name: