Speeding up compiled apps startup

August 22, 2012 32 Comments

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.

32 Responses

Andi August 22, 2012 at 17:04 Reply

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.

f = dir(prefdir);
for index = 1: numel(f)
    if f(index).isdir && ~strcmpi(f(index).name, '.') && ~strcmpi(f(index).name, '..')
        fprintf('deleting %s ...n', fullfile(prefdir, f(index).name));
        rmdir(fullfile(prefdir, f(index).name), 's');
    end
end

Yair Altman August 22, 2012 at 17:16 Reply

@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…
Andi September 1, 2012 at 12:12 Reply

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.

Yair Altman September 1, 2012 at 12:17

Ah! – it makes sense now. Strange behavior on the part of the compiler, I must say

alvaro562003 December 18, 2016 at 12:10 Reply

As of today, December 18 2016, prefdir is: C:\Users\admin\AppData\Roaming\MathWorks\MATLAB\R2016a

The content of this directory is:

18/12/2016  09:23              .
18/12/2016  09:23              ..
18/12/2016  10:51             1ÿ291 publish_configurations.m
18/12/2016  10:51               220 run_commands.m
18/12/2016  09:14         1ÿ817ÿ222 History.bak
18/12/2016  11:01         1ÿ817ÿ797 History.xml
18/12/2016  10:49             4ÿ668 matlab.prf
18/12/2016  09:23            18ÿ143 matlab.settings
18/12/2016  11:01            10ÿ081 MATLABDesktop.xml
18/12/2016  09:20             9ÿ092 MATLABDesktop.xml.prev
18/12/2016  09:20             7ÿ420 MATLAB_Editor_State.xml
14/04/2016  18:30             4ÿ130 comparisons.settings
07/04/2016  09:03                 0 creation.timestamp
10/03/2016  12:44               731 dastudio.prf
24/03/2016  20:42             2ÿ040 database.settings
07/04/2016  09:03              HtmlPanel
10/03/2016  10:14                87 javaclasspath.txt
19/10/2016  10:23               618 matlabprefs.mat
29/07/2015  09:37             8ÿ963 MBUILD_C_win64.xml
29/07/2015  09:37             8ÿ978 mex_C++_win64.xml
03/09/2015  19:50             8ÿ521 mex_C_win64.xml
22/02/2016  10:44                40 MLintDefaultSettings.txt
07/04/2016  09:13             1ÿ298 mwKeyStore
07/04/2016  09:13             6ÿ144 parallel.settings
27/01/2016  22:38               201 shortcuts_2.xml
10/03/2016  12:29               138 systemtest.cfg
07/04/2016  09:13               772 thisMatlab.pem

I would advise not doing it. Personally, I will not do this operation.

Sam May 14, 2020 at 06:12 Reply

Doesn’t work for me! I am using Matlab 2018a, no different at all, even the exe file size is the same.

Cris August 23, 2012 at 02:12 Reply

Some years ago I used to manually unpack the archive file using the $MATLABROOT/toolbox/compiler/deploy/$ARCH/extractCTF utility. Things have changed in the compiler, but the utility still exists, so this technique might still work.

Ofek Shilon March 29, 2017 at 17:43 Reply

As of matlab 2016a, the path to the utility (at least on windows 10) is $MATLABROOT/bin/$ARCH/
Hao Deng December 10, 2018 at 11:13 Reply

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.

Matt W August 23, 2012 at 07:41 Reply

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
Dirk Engel October 3, 2012 at 04:38 Reply

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…

Hao Deng December 10, 2018 at 09:43 Reply

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?

Dani October 6, 2012 at 08:42 Reply

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.
ECS_VUW_Kevin November 8, 2012 at 16:04 Reply
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:
```
The page you were looking for is not available in this version of the Documentation. 
You can use the search box or browse the products below to find related information. 
You can also view archive documentation for prior releases.
```
however, when I try to search the previous version, I get told
```
Access to archived documentation is a benefit for licensed users of MathWorks products.
Your account must be associated with a license. 
```
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.

Yair Altman November 8, 2012 at 16:15 Reply

@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…
Yair Altman July 24, 2013 at 13:26 Reply

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.
Ofek Shilon March 29, 2017 at 17:35 Reply

@Yair link is broken again

Yair Altman April 2, 2017 at 12:25

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

xiaogp13 July 8, 2013 at 04:39 Reply

It doesn’t work!

Yair Altman July 8, 2013 at 04:42 Reply

@xiaogp13 – what doesn’t work? please be more specific…
xiaogp13 July 8, 2013 at 04:59 Reply

I have set MCR_CACHE_ROOT, but my compiled application still startup too slow!

Yair Altman July 8, 2013 at 05:03

The MCR_CACHE_ROOT trick is apparently platform-dependent. As you can see from the other comments here, it does work for some people.

eric August 4, 2013 at 10:28 Reply

How do you introduce the set MCR_CLASS_ROOT command, Matlab doesn’t like it, is it a batch file?

Yair Altman August 4, 2013 at 10:30 Reply

@Eric – it is an Operating System environment variable, not a Matlab variable…

eric August 4, 2013 at 17:02

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
Yair Altman August 4, 2013 at 23:58

Look at the link that I provided above

Matthias August 5, 2013 at 06:16 Reply

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.

Yair Altman August 5, 2013 at 06:31 Reply

@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.

Andy November 21, 2013 at 09:42 Reply

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
Clayton Chu April 28, 2014 at 14:32 Reply

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.
Deployed Matlab application using significantly more memory than Matlab scripts | Ngoding November 19, 2014 at 05:50 Reply

[…] archive and startup the MCR runtime, just like the delay you see when you start the MATLAB IDE): undocumentedmatlab.com/blog/speeding-up-compiled-apps-startup. – Amro Jun 28 '13 at […]
dariush September 23, 2015 at 17:14 Reply

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?

HTML tags such as <b> or <i> are accepted.
Wrap code fragments inside <pre lang="matlab"> tags, like this:

<pre lang="matlab">
a = magic(3);
disp(sum(a))
</pre>

I reserve the right to edit/delete comments (read the site policies).
Not all comments will be answered. You can always email me (altmany at gmail) for private consulting.

Click here to cancel reply.

Related posts:

32 Responses

Leave a Reply