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

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

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.

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

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.

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

^[16]

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.

@Kevin – the webpage that you mentioned can be accessed ^[17] (no MathWorks license required). I discussed this doc-archiving mechanism some weeks ago, ^[18]. 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: ^[2]

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):
^[19]
[20]

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 ^[21], 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.

[…] 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 […]

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?