Slow screen reaction matlab GUI

Hellow, I have build a GUI with about 20000 rules of code. This makes that my screen reacts very slow when i want to adapt the code. Does anybody how to increase my screen reaction time?

Answer 1

[Jan]

What is a "rule of code"? Do you mean de -crease the screen reaction time?

If you want to improve the speed of the code, use the profile command to find the bottle-neck at first. It is not useful to optimize code, which needs 1% of the run-time only.

After you have found the bottle-neck, post the relevant part of the code here. Otherwise it is hard to guess the reason of the slow processing and only very rough general advices can be provided: pre-allocate, try a vectorization when no large intermediate arrays are required, remove repeated calculations out of the loops, process arrays in column order.

[Jan]

[Copied from answer section] Dries wrote:

Excuse me for the unclear question: *Rules of code = lines of code. I indeed want to decrease the screen reaction time or increase my screen performance.

The execution of the code is not the problem. This goes very quick but the problem is that my screen reacts very slow when i want to adapt my code. So if i want to copy paste something, i have to wait for several seconds and that bothers me.

[Jan]

The screen reacts with a frequency of 60Hz or higher. So it is a program which reacts slowly. Now please tell us, which program this is. What does "adapt the code" mean? Do you mean, that the editor reacts slowly? This might be caused by the code analyzer. Then it would help to split the M-file into parts and create an own M-file for each callback.

[Dries]

Is is the editor that reacts slowly. This is all standard matlab R2011b.

Answer 2

[Sean de Wolski]

The editor is sluggish because of the various background processes. One of these is the Code Analyzer, so the first thing you can do is turn it off in preferences. I also heard that (while editting code only) adding the command:

exit

To the first line of the function will disable all of this without having to shut off code analyzer and mtree. Of course you'll want to remove this line before running the file :)

Alternatively, (my guess is that you're working in GUIDE) you can extract some of the functionality to other files. These could be reused functions or functions called by callbacks. This will allow you to shrink the overall file size and have better modulerized code as well.

[Jan]

@Sean: I tried not to remove the exit on top of the code and to my surprise the code consumes much less resources than before: Less memory, less processor load, less disk access. And although disabling the code analyzer means a severe drawback for the integrity of the code, even less errors occurred. Thanks, Sean, your suggestion of exit made my day.

@Dries: There are more reasons to split the M-file into parts: The readability and maintainability is increased, because the different parts can be edited independently from each other. I'm split my codes into several parts usually:

1. Creation of the GUI
2. GUI callbacks in one function, where the 3rd input let the code branch to the callbacks of the different elements.
3. Code to convert the GUI settings into parameters to start the actual calculations.
4. The actual processing.

This modular structure allows e.g. to start the processing from a batch job also or modify the GUI layout without the danger of touching the part for the calculations.

[Sean de Wolski]

@Jan, it was this answer that spawned this:

http://www.mathworks.com/matlabcentral/answers/13577#answer_95170

When I first read it, and the author's other couple of answers, I was going to flag/delete them for abuse. But then I realized it worked :)

[Jan]

@Sean: As far as I can see, exit on top of the code let the rest become dead code. So if 0 and a trailing end would be similar, but it would not allow subfunctions inside the file. But an initial exit should have the same problem, because the file becomes a script then. I get a lot of red MLint marks for all subfunctions, when I add exit on top under Matlab 2009a at least.

Anyway, an initial exit is like a message from Bodhidharma: He went from India to China to not tell what he found out, because this was it, what he found out. There is no kharma, there is no treasure, just vastness. I believe that exit helps to colve the problem. And in addition it is Matlab-Zen.

[Sean de Wolski]

I was thinking this was MATLAB zen:

zen = @()why(260);
zen()