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.
On Linux:
export MCR_CACHE_ROOT=/tmp/mcr_cache_root_$-- USER # local to host mkdir -p @MCR_CACHE_ROOT ./myExecutable
On Windows:
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.
One thing with the modified code is that it is necessary to add an attachment to send an...
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.
@Andi – this is strange. Can you tell how you came across this and/or what the logic behind deleting all preference files is? This is obviously a very destructive operation and I would not advise doing it without a very good reason…
Yair, please note that I do not delete the preference files in the preference root directory. I only delete the subdirectories, which I believe are created by the compiler. Furthermore, I have not found anything in the MatLab documentation, which would suggest that these subdirectories are important.
I have noticed that the executables of small programs got bigger and bigger after each compilation (> 10 MB) without any obvious reason. In the log of the compiler I saw that the compiler includes many files from these subdirectories. I then deleted these subdirectories and found that the executables are suddenly small again (a few hundred KB). I have not observed any adverse effects.
Ah! – it makes sense now. Strange behavior on the part of the compiler, I must say
As of today, December 18 2016, prefdir is: C:\Users\admin\AppData\Roaming\MathWorks\MATLAB\R2016a
The content of this directory is:
I would advise not doing it. Personally, I will not do this operation.
Some years ago I used to manually unpack the archive file using the
$MATLABROOT/toolbox/compiler/deploy/$ARCH/extractCTFutility. Things have changed in the compiler, but the utility still exists, so this technique might still work.As of matlab 2016a, the path to the utility (at least on windows 10) is
$MATLABROOT/bin/$ARCH/Hi, I found that extractCTF did work. But after extraction, what should I do? Put the extracted files into MCR cache dir? It didn’t work in this way since MCR simply ignore the extracted files and did extraction again.
Hi Yair,
I can confirm that setting the MCR_CACHE_ROOT variable is indeed the way to go. Just ran accross this on a .NET deployment of one of our apps and it improved the startup time and a number of other headaches considerably.
On our desktop apps we generally just compile with the ctf archive separately (-C switch on mcc). This is for two reasons 1) We unpack once to a folder under the executable. 2) Our CTF contains a number of resource files and preferences . Although one can’t swap out any .m code you are free to manipulate your other resources included in there. This was also another reason we went to the MCR_CACHE_ROOT for the .NET deployment. For example we use the Matlab report generator for some reports. Unfortunately the stylehseet (.rgs- actually an xml) seems to only take absolute file paths for resources like bitmaps we use for report headers . So on first time startup we have the software figure out where it is installed and then where the absolute location of the resources are and then edit the stylesheet.
Best Regards
Matt
Yair:
I cannot confirm! Where did you find the information that extracted CTF files are “normally deleted when the user logs out”? With my setup (Win 7, MATLAB 2010b, compiled without -C flag, MCR_CACHE_ROOT not set) unpacked files in the user’s temp directoy (%LocalAppData%\Temp\\mcrCache7.14\ in my case) do not get deleted on log-out or reboot but are kept for later use. Up to now this was “normal” behavior for me. But I don’t like the idea of getting this behavior just by chance, so if anybody has an explaination…
In my case, things go like this: Without setting the MCR_CACHE_ROOT env variable, compiled exe will be extracted to path like this %LocalAppData%\Temp\\mcrCache83\XXX. It will usually not be deleted after closing. However, when I open another app which call matlab compiled dll(not exe) , the previous extracted files are totally removed. This phenomenon seems remain exactly the same when I set the MCR_CACHE_ROOT. So the question should be: how to prevent MCR from cleaning extracted files when switching between extracting exe and extracting dll?
I just tried this with 2011b on Windows 7. I compiled my application with the -C switch, extracted the content of the CTF with extractCTF.exe and set the MCR_CACHE_ROOT to the directory with the extract. The startup time is the same if I start the application like this or if I do it the standard way (i.e. no -C, no extract, no MCR_CACHE_ROOT). It takes about 7 seconds until I see first window appear. Maybe this is due to the SSD disk.
The link you provide under the word MCR_CACHE_ROOT in the first paragraph
http://www.mathworks.com/help/toolbox/compiler/brl4_f1-1.html
no longer seems to exist.
Matlab’s web presence first gave me a “you need an account to access” message (presumably because it’s top secret information?) and, having set one up, I then got told:
however, when I try to search the previous version, I get told
so, just wanted to say thanks for your resource, which I found when trying to find the content from the top secret pages that Matlab no longer want anyone to see.
@Kevin – the webpage that you mentioned can be accessed here (no MathWorks license required). I discussed this doc-archiving mechanism some weeks ago, here. In this day and age, once a webpage has been posted, it is difficult to get rid of it completely…
MathWorks moved the contents of the webpage that explains MCR_CACHE_ROOT and the CTF embedding feature to here: http://www.mathworks.com/help/compiler/mcr-component-cache-and-ctf-archive-embedding.html
Too bad they didn’t automatically redirect traffic from the old link, but at least the information has not been deleted.
@Yair link is broken again
Here are the updated links on the Mathworks website (note the minute differences between the pages):
http://mathworks.com/help/compiler_sdk/ml_code/mcr-component-cache-and-ctf-archive-embedding.html
http://mathworks.com/help/compiler_sdk/cxx/matlab-runtime-component-cache-and-deployable-archive-embedding.html
It doesn’t work!
@xiaogp13 – what doesn’t work? please be more specific…
I have set MCR_CACHE_ROOT, but my compiled application still startup too slow!
The MCR_CACHE_ROOT trick is apparently platform-dependent. As you can see from the other comments here, it does work for some people.
How do you introduce the set MCR_CLASS_ROOT command, Matlab doesn’t like it, is it a batch file?
@Eric – it is an Operating System environment variable, not a Matlab variable…
alright, unfortunately I’m a student w/ no license, so I can’t access the mathworks page, I’m not entirely sure how to set the variable in windows for my program
Look at the link that I provided above
This might be a bit offtopic but I was having a problem with my MCRCache. For some reason when I deploy my executable to a different system (using a 3rd Party Installer, though all that one really does is copying some files) when I run the executable for the first time the MCRCache is created. However something’s wrong with it and the first time I get an error message from the Visual C++ Runtime (probably from the redistributables that the MCR installs during its setup process).
Anyway, after the first start the error message no longer appears and the executable works as intended.
Is there any way I could ‘pregenerate’ the mcrcache and deploy it alongside the executable? This is not just about the .CTF (at least from my understanding). The CTF File (if I generate one as opposed to just compiling it into the executable) is only 8MB whereas the MCRCache is 23MB.
@Matthias – this sounds like a compiler or installer bug. I suggest that you contact MathWorks customer support about this. Please place a followup comment here if you learn anything new.
Hi,
I succesfully changed the mcr cache folder to ‘C:\matlab_mcr_cache’ by setting the MCR_CACHE_ROOT as a system variable. Files added to the exe (some automatically by mcc, and some manually by -a) do indeed exctract to something like ‘C:\matlab_mcr_cache\mcrCache7.17’, but they are automatically deleted when the program is finished, thus giving no potential gain in speed. Am I doing something wrong? I do not use -c, since I want a single exe-file.
/Andy
Hi Yair –
I was wondering if this long start-up time still exists in MATLAB R2013b or newer. They switched to a shiny new deploytool, but I wonder if anything was done on the backend to improve startup time. It looks like MATLAB Compiler jumped from v4.18.1 to v5.0 between R2013a and R2013b.
Pingback: Deployed Matlab application using significantly more memory than Matlab scripts | Ngoding
Hi Yair.
I wrote a fairly complex GUI in R2014b and i have the problem of very slow startup. Could you please explain a little more on the solution you mentioned here. What steps should i take to set MCR_CACHE_ROOT and so on? Where can i set this options?