Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Excutable made by MATLAB compiler very slow

900 views
Skip to first unread message

Jim River

unread,
Feb 19, 2005, 6:49:11 PM2/19/05
to
I used Matlab 7 (Rel.14) compiler to make executable program, and
found the execution is very slow. It takes about 3 seconds for the
computer to respond, not matter how simple the program is. (In my
example, the function has only one display command disp("Hello
World!"), but it still takes about 3 seconds for the program to run)

Matlab 6 (Rel.13) seems much faster. Anybody knows why?

Thanks,
Jim

Y Mehta

unread,
Feb 19, 2005, 11:25:42 PM2/19/05
to
snip: Slow start of compiled program

I second it. I have been facing the same problems. On a "Fast"
machine a simple GUI takes upto 10-15 seconds to pop up.

I will appreciate any help/comments on this topic

Herbert Ramoser

unread,
Feb 22, 2005, 1:57:35 AM2/22/05
to

If you do not need Java in your executable you can disable it. This
significantly reduces startup time: mcc -R nojvm ...

-Herbert

Jim River

unread,
Feb 22, 2005, 1:16:54 PM2/22/05
to
I tried this nojava switch, no impact on the launch time.

This seems to be an known problem, see the following link

<http://www.mathworks.com/support/solutions/data/1-T6Y3P.html?solution=1-T6Y3P>

The explanation (or performance) is far from satisfactory. I agree
that since the new version supports more functionalities, it may be
slower. However, if a program does not use these functions, the
compiler should be smart enough to include only relavent stuff, not
waste time.

We should challenge Mathwork to improve the performance. Too often we
find excueses for sloppy programming.

Jim

Michael Herdy

unread,
Mar 4, 2005, 10:01:26 AM3/4/05
to
With the nojava switch, I get a runtime crash with my application. I
have startup times of more than 30 sec on a 1 GHz machine. Matlab
support cannot help up to now. I would appreciate any hint.
Michael

James Couves

unread,
Mar 4, 2005, 10:37:52 AM3/4/05
to
Jim River wrote:
>
>
> I tried this nojava switch, no impact on the launch time.
>
> This seems to be an known problem, see the following link
>
> <http://www.mathworks.com/support/solutions/data/1-T6Y3P.html?solution=1-T6Y3P>
>
> The explanation (or performance) is far from satisfactory. I agree
> that since the new version supports more functionalities, it may be
> slower. However, if a program does not use these functions, the
> compiler should be smart enough to include only relavent stuff, not
> waste time.
>
> We should challenge Mathwork to improve the performance. Too often
> we
> find excueses for sloppy programming.
>

Mostly, we should encourage Mathwork to guives
as back, at least also, the version 3 compiler.

Cristian Müller

unread,
Mar 6, 2005, 6:21:13 AM3/6/05
to
I think that the team from Matlab is very scared,they run 1024 bit
encription in the resulting exe.
So there is a great waste of time at execution.

Michael Robbins

unread,
Mar 6, 2005, 12:06:25 PM3/6/05
to
> I think that the team from Matlab is very scared,they run 1024 bit
> encription in the resulting exe.
> So there is a great waste of time at execution.

RE the encryption, TMW is responding to their customer's needs, and
so it is not a waste.

The instatiation time you're experiencing seems very excessive,
though. I have compiled GUIs with the new compiler without that
effect, but I may just be lucky.

Can you use an older version of the compiler? I don't remember if
that will compile GUIs. If not, you may want to readdress why you
need to compile your GUI. You may want to use p-code or you may want
to compile other parts of your code and not your GUI, or recreate
your GUI in another language like VC++ and call your MATLAB functions
that way. It's not hard to do.

I'm sure TMW will fix the problem shortly. They are spending a lot
of time and money on their compiler development and have come a long
way since v2.

Rajeev

unread,
Mar 6, 2005, 1:15:56 PM3/6/05
to

Michael Robbins wrote:
> > I think that the team from Matlab is very scared,they run 1024 bit
> > encription in the resulting exe.
> > So there is a great waste of time at execution.
>
> RE the encryption, TMW is responding to their customer's needs, and
> so it is not a waste.

I don't buy this. Some customer needs encryption, so everybody suffers
a slowdown ?

My two cents,
-rajeev-

Rajeev

unread,
Mar 6, 2005, 1:24:50 PM3/6/05
to

Jim River wrote:
<...>

> This seems to be an known problem, see the following link
>
>
<http://www.mathworks.com/support/solutions/data/1-T6Y3P.html?solution=1-T6Y3P>
>
> The explanation (or performance) is far from satisfactory. I agree

Quote from the above link:

"Once started, your applications should run with a speed similar to the
uncompiled application in MATLAB."

I used to think there were 3 reasons people compile Matlab code:

1: ability to run application in a non-Matlab environment
2: ability to hide code from user
3: faster operation

Did #3 get thrown out the window ? Or has the interpreter speeded up
so much
that there is no longer a compile advantage ?

Now I'm curious : there's a bunch of folks following this thread and
interested in compiling their Matlab application. Could you share your
reasons for compiling with the group ?

Thanks,
-rajeev-

Michael Robbins

unread,
Mar 6, 2005, 3:20:47 PM3/6/05
to
> I don't buy this. Some customer needs encryption, so
> everybody suffers a slowdown ?

You are assuming that encryption is the problem. I doubt it is.
Many programs that do encryption on-the-fly are very fast and you
wouldn't likely see any performance hit, much less one on the order
of minutes. P-code, for instance, is encrypted and runs at least as
fast as m-code.

<snip>


> 1: ability to run application in a non-Matlab environment

This seems to currently be the primary purpose of the compiler. TMW
has switched their emphasis from producing C code and compiling it,
to making the universe of MATLAB functions compilable. With the high
cost of MATLAB, it is very desirable to be able to run your program
on a machine without a MATLAB license.

> 2: ability to hide code from user

As discussed above, a very valid purpose.

> 3: faster operation
>
> Did #3 get thrown out the window ? Or has the interpreter speeded
> up so much that there is no longer a compile advantage ?

I wouldn't say #3 was thrown "out the window," but maybe it's less of
a priority. Maybe that's why it's #3 and not #1 ;)

The interpreter did speed up dramatically with the introduction of
JIT and, as I mentioned above, TMW seems to have put more emphasis on
compiling all MATLAB functionality, something that was not possible
with v2, rather than faster excution with limited scope.

Peter Nabos

unread,
Mar 6, 2005, 11:40:55 PM3/6/05
to
>
> The interpreter did speed up dramatically with the introduction of
> JIT and, as I mentioned above, TMW seems to have put more emphasis
> on
> compiling all MATLAB functionality, something that was not possible
> with v2, rather than faster excution with limited scope.

That is not the impression we get from the
numberous users complains on (and they often
restrict to that) start up time of compiled code.

On my side, I don't event want to hear about
something that forces us to deploy a ~100Mb
background to run a compiled code that can be
on the order of ~1 Mb.

I realy regret that, because at long as it lasts Matlab stoped as R13.

0 new messages