A few weeks ago, I discussed a splash wrapper application that alleviates much of the pain of the slow startup of deployed (compiled) Matlab applications. While such a splash wrapper is indeed useful, it may also be possible to achieve an actual speedup of the compiled app’s startup using the MCR_CACHE_ROOT environment variable.
The following has been reported to me by a reader of this blog. Please note that I cannot independently confirm the correctness of the report (if anyone can let me know I would be grateful):
Normally, the MCR and the stand-alone executable is unpacked upon every startup in the user’s temp dir, and deleted when the user logs out. Apparently, when the MCR_CACHE_ROOT environment variable is set, these files are only unpacked once and kept for later reuse. If this report is indeed true, this could significantly speed up the startup time of a compiled application in subsequent invocations.
export MCR_CACHE_ROOT=/tmp/mcr_cache_root_$-- USER # local to host mkdir -p @MCR_CACHE_ROOT ./myExecutable
REM set MCR_CACHE_ROOT=%TEMP% set MCR_CACHE_ROOT="C:\Documents and Settings\Yair\Matlab Cache\" myExecutable.exe
If you wish to set this env variable permanently on Windows, look at the explanation provided here.
Setting MCR_CACHE_ROOT is especially important when running the executable from a network (NFS) location, since unpacking onto a network location could be quite slow. If the executable is run in parallel on different machines (for example, a computer cluster running a parallel program), then this might even cause lock-outs when different clusters try to access the same network location. In both cases, the solution is to set MCR_CACHE_ROOT to a local folder (e.g., /tmp or %TEMP%). If you plan to reuse the extracted files again, then perhaps you should not delete the extracted files but reuse them. Otherwise, simply delete the temporary folder after the executable ends. In the following example, $RANDOM is a bash function that returns a random number:
export MCR_CACHE_ROOT=/tmp/mcr$RANDOM ./matlab_executable rm -rf $MCR_CACHE_ROOT
Setting MCR_CACHE_ROOT can also be used to solve other performance bottlenecks in deployed applications, as explained in a MathWorks technical solution and a related article here.
In a related matter, compiled Matlab executables may fail with a
Could not access the MCR component cache error, when Matlab cannot write in the MCR cache directory due to missing permission rights. This can be avoided by setting MCR_CACHE_ROOT to a non-existent directory, or to a folder in which there is global access permissions (/tmp or %TEMP% are usually such writable folders) – see related posts here and here.
Thanks for the suggestion. In addition, I have found that running the following snippet before compiling significantly reduces the size of the executable and the time to unpack the executable.