GUI menu getting slower with multiple GUI opened

Hi,

i'm experiencing a strange performance slowing down of a GUI, when using the menu callback.

My GUI (main), via nested menus is opening other instances of another GUI (seconday), and after two instances on the seconday GUI are opened, the menu drop down became slower and slower

looking at the profiler this is the operation causing this very long time execution (self time)

@(hObject,eventdata)Main('menu_Callback',hObject,eventdata,guidata(hObject))

and this is appening for each menu and sub menu

After opening two secondary GUI, this take 90 seconds, just to expand the menu.

Do you know why this is happening and how to fix it?

thanks

[Shameer Parmar]

Hello Alessandro,

So here you can also apply logic to close previous GUI as soon as the new GUI opned.

as your code open one GUI then in next line apply the 'close()' command to close the previously opened GUI, so that it will not create any confusino to you..

so if there are 2 GUIs like GUI1 and GUI2, and GUI1 is already opened and you want to open GUI2 then apply command like this..

GUI2; % for opening GUI2
close(GUI1); %for closing GUI1 and keeping GUI2 as opened..

Please chekc if this can help you..

[Alessandro Cicchelero]

All the opened GUI musts stay opened and this is done on pourpose...

There should be something related to the listeners management, that really impact on performances.

Looking at the computer CPU management, a constant usage of the memory is requested, in trying to open the menu items.

I haven't red nothing about limitation on the maximum number of GUI opened at the same time, but after 3 performances decrease drastically.

[Jan]

If it takes 90 seconds to open a menu, something must be computed during this time. The current explanations do not reveal, what it is. Can you post a minimal working example, which reproduces the problem?

Which "menu" are you talking of? One of the figure or a popup menu?

Is the problem reproducible? Do you ran out of memory, such that the slow disk caching blocks the processing?

[Alessandro Cicchelero]

I've realized the issue is not relevant to the number of opened GUIs but to the number of listeners added. After a certain amount, this drastically impact on the matlab performances, taking so lonk even to open a menu that has no code inside.

The limit seems to me at 50 listeners.

Do you know if there is these sort of limitation and how to work it around?

Thanks

[Rik]

It might be a tangent, but I wonder if the performance wouldn't improve if callbacks used the normal callback structure of calling a function directly, instead of the wrapping with Main('menu_Callback',hObject,eventdata,guidata(hObject)

[Alessandro Cicchelero]

thanks for the suggestion, but this doesn't work.

At the very beginning of the investigation I was wandering if the guidata command was the bottleneck, But looking at the profiler, as described, it is only self time.

May be Mathworks knows about this limit, but don't advertise it :-)

I should find a way to reduce it or to avoid user to generate more than these 50

Answer 1

[Alessandro Cicchelero]

The manu I'm refferring to is the uimenu.

My main GUI has these custom menus, which have 3 levels, the first two has no code inside, and the 3rd one is calling an instance of the secondary GUI.

You can call as many secondary GUIs as you want, since the "GUI Allows Only One Instance to Run (Singleton)" disabled, while the main GUI has this flag enabled

Looking at the profiler seems these 1st and 2nd level uimenu is wasting time only calling the menu callback, and the 99% of the time is self time.

This don't put me in condition to understand what is causing this. The only thing I've realized is that this is happening after the second secondary GUI is displayed.

The entire project contains Intellectual Properties, and cannot be shared.

I've generated an example of these two GUIs, but unfortunately in this case the issue is not present.

The secondary GUI is receiving the handles of the main GUi and the main GUI is storing the information of the Secondary GUI (basically the hobject.

In attachment the example

[Jan]

"Looking at the profiler seems these 1st and 2nd level uimenu is wasting time only calling the menu callback, and the 99% of the time is self time."

It would be useful to show us the output of te profiler. Currently it is hard to analyse the problem without seeing any details, but only by reading your interpretations.

If the issue does not exist in the given example code, you can use this as point to start: Find out, what the difference is between the example and your real code. Maybe the 2nd fig file contains thousands of graphic objects, which are invisible or hidden behind others. Then finding a specific handle would take a lot of time.

[Alessandro Cicchelero]

the profiler reveals exactly what I've described : Self time

but this is generated by the listener management.

I've realized there are 48 listener, and trying to adding more the result is a general matlab slow responce, and not only the uimens.

There shoud be a limit in the listener management, and probably i've found it...

[Jan]

@Alessandro: "The profiler reveals: Self time" does not allow to understand, what's going on. Self time of what? "this is generated by the listener management" - what is generated?

As long, as the posted code does not reproduce the observed behavior, I do not see a reason to assume, that there is a hard limit in the number of listeners.

Currently the problem has not been explained in a way, which allows to understand or reproduce it.