That is more "robust" but it just changes what has been swapped-out by the OS, not the fact that the OS had to resort to a swap-out in the first place. And if you have a swapfile (or as Win10 likes to call it, a "paged pool") then you're toast because then the OS will happily swap application and even OS memory out to disk in order to free-up ram for Matlab. This still will not resolve the problem completely as it won't track either non-Matlab use of system memory or "available ram" (with or without a swapfile). That is why the above limit is based on installed physical ram, not "available ram".
Before MATLAB was "improved", it would happily create the requested array even if it meant using "disk memory" (from a swapfile, the opposite of a ramdisk) and you'd have to reboot your system to clear the RAM and get it to respond.MATLAB wouldn't actually crash the system as long as there was sufficient "disk memory" available to complete the command but the system was so slow to do anything that you'd want it to crash. Any machine-state with low responsiveness is a problem unless you are willing to go have a cup of coffee or something. The point is to keep that condition from happening in the first place, but that is not the only condition that is a problem.
MATLAB will screen the code for the potential problem and abort before actually executing such code. The command does not fail because the required trigger memory never gets used and so it does not crashes the system.
0 kommentar(er)
