Is the start up time in compiled applications using 2013b better?

I had been been using Matlab 2012b. I had few deployed application using this version which took significant time to load up.

I know Matlab 2013b have many enticing features which provide a more professional installation for the deployed application. My question is did this became better in 2013b version of compiler? I have tried too look in blog posting etc, but couldn't find any comments regarding this. Do you guys have any thoughts or experiences regarding this.

[Matt J]

The slow start-up time usually occurs the first time the deployed .exe is executed, but should improve on subsequent executions. You say you're seeing otherwise in R2012?

[Amit]

Yes. Generally minute or higher. The same program (.m version) loads within seconds via matlab.

But, I thought that was a known issue. Thats why the splash screens etc to atleast verify that something is happening.

[Matt J]

Well, whatever you're seeing sounds like it could be application dependent or platform dependent. I have applications compiled under 2012b that take 6 sec. to start up. I haven't tried with R2013b.

[Amit]

Interesting. What determines the start up time? Previously I simply compiled applications using matlab compiler application. Should I had done something different?

[Matt J]

I have no idea what's going on under the hood. GUI functions (e.g., uigetfile) and plotting functions always seemed to me to invoke some time-consuming library loading, but that's only my vague impression.

Are you saying all your exe's take 1 minute or more to get running?

[Matt J]

What about a simple "Hello World" to the command line?

[Amit]

To be honest, I only have created 2 exe's which are GUI applications. And they both behave the same way. Though, the .m files loads within seconds.

However these are important as they get used by others without MATLAB. I rarely use exe's (only for testing) as I can run the file directly via matlab (which is way faster).

[per isakson]

"... the vast majority of the launch time is due to MCR load time," according to Splash window for deployed applications

[Amit]

True but that blog article was written in 2012. I was wondering if that has improved in the recent compiler.

The reason I am interested is because I can upgrade to 2013b, but if the start up is still issue, I'll have to think about it.

[Walter Roberson]

You can request a Trial version to test with.

Answer 1

[Image Analyst]

I haven't done actual timing, but it's not significantly different. The first run, like Matt said, take longer, maybe 90 seconds, because it has to unpack a bunch of stuff. Subsequent runs don't need to do that so they're shorter but still on the order of a minute or so. I have R2013a and R2013b both installed on my computer, both in 32 bit and 64 bit. Maybe I'll do some timings over the weekend.

[Amit]

This is something I need to figure out. Like you mentioned as well as Matt in his comment, the first load unpacks bunch of stuff. But I think that bunch of stuff gets unpacked in a temporary directory or something. And once one restarts the computer, its back to time 0.

Is there a way around it. Like unpacking it somewhere so that it doesn't get deleted the second time and has to go through the unpacking again.

[Image Analyst]

It's a hidden directory (I think), but not a temporary one. I tell Windows not to hide any of my folders so I'm really not sure what's technically hidden or not unless I check the attributes. Anyway, if you set the environment variable MCR_CACHE_ROOT to . (dot) you'll see it unpack it right there where the executable lives, instead of that hidden directory. Now you can see all the stuff, and you might be surprised at some of the stuff it includes because it re-builds the directory tree structure. But reboot and that stuff is still there.

[Amit]

That is very helpful. Thank you for that Image Analyst.

It is possible to do this with the installer package. Because I want to give the package to other people, and it will harder to tell them how and what regarding setting MCR_CACHE_ROOT