MATLAB Answers

tic, toc, apear to be reporting incorrect times when called in App Designer button callback

8 ビュー (過去 30 日間)
AdamG2013468 2019 年 7 月 31 日
コメント済み: Walter Roberson 2019 年 8 月 1 日
I am using App Designer to build an app that, among other things, imports a .csv after pressing an "import" button.
The callback function for this import button includes only about 80 lines of code, but by my estimates takes approximately 30sec-1.5 min. I placed the "tic" function at the beginning of the callback function, and the "toc" function at the end. I also have an edit text field that reads out the current status of the import callback. Using the status edit field as reference, i can tell how long the callback function is "Processing...". My issue is that when the toc value is returned to the workspace and my EditField value, it is calculating the stop watch time as approximately 1.5 seconds, when it is more like 1 min. For example, my code follows the format below.
function ImportButtonPushed(app, event)
app.EditField.Value = 'Processing';
%80-90 lines of code
app.EditField.Value = sprintf('Completed: Processing Time = %f', toc)
Has anyone experience similar issues before? Or am I making a simple mistake?

  2 件のコメント

Adam 2019 年 8 月 1 日
I tend to use the profiler rather than tic toc when I want to examine multiple lines of code, especially involving builtin functions and implicitly called ones, e.g. you will often find drawnow takinga lot of time where a GUI is concerned. I've often found java GUI component rendering to be quite slow, though I often use the GUI Layout Toolbox and one of the flaws of the layouts is their effect on speed and calls to drawnow.
Walter Roberson
Walter Roberson 2019 年 8 月 1 日
Unfortunately the profiler tends to disable JIT, and so can give very different timings than production code.



Stephen Cobeldick
Stephen Cobeldick 2019 年 8 月 1 日
Try specifying the output variable:
t = tic();
Or record the time yourself:
tstart = now();
(multiply by 24*60*60 to get seconds)

  4 件のコメント

表示 1 件の古いコメント
AdamG2013468 2019 年 8 月 1 日
I have discovered that the problem is not with tic/toc, but now i have a new problem. Somehow, my last line of code,
app.EditField.Value = sprintf('Completed: Processing Time = %f', toc);
is what is taking the bulk of the time. Using toc after the sprintf function counts an elapsed time of approximately 120 seconds! How could this one simple line be requiring so much processing time? Also, a new error that i will see occasionally is:
java.lang.OutofMemoryError: Java heap space %message in all red error code
Which i assume is part of the explanation as to why sprintf is taking so long.
I know this is a seperate question altogether. Any input would be appreciated.
AdamG2013468 2019 年 8 月 1 日
Per usual, a cursory Google search has revealed a partial answer.
I increased the Java Heap Memory size from the default 768 MB to a larger value, which aided in reducing the processing time. However, i am still seeing times in excess of 90-100 seconds for the single sprintf line.
AdamG2013468 2019 年 8 月 1 日
Changing the Java Heap Memory size helps some. The wait times for the EditText field and other graphics objects such as a list box to update is what is taking a long time. Using toc throughout the callback indicates that the script itself is being processed rather quickly (1.5-2 seconds), but for the actual app UI to update its graphics takes around 80-100 seconds.
Is their a solution to this, or is this a natural consequence of MATLAB/Java limitations?


その他の回答 (0 件)

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by