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

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.

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?

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

As of matlab 2016a, the path to the utility (at least on windows 10) is $MATLABROOT/bin/$ARCH/

@Yair link is broken again

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.

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.