bugGNU Octave - Bugs: bug #42255, Octave GUI command window become...

 
 

bug #42255: Octave GUI command window become very slow

Submitter:  None
Submitted:  Thu 01 May 2014 02:32:01 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Ralph Reinhold Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 3.8.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 06 May 2014 04:41:29 PM UTC, comment #16: 

I have already closed the bug report.

Torsten Lilge <ttl>
Group Member
Tue 06 May 2014 04:33:53 PM UTC, comment #15: 

While I have not updated for the change, I consider this closed. How do I handle that?

Anonymous
Tue 06 May 2014 04:28:00 PM UTC, comment #14: 

I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/0f9ed79fb206
which truncates the displayed width of history entries.

Torsten Lilge <ttl>
Group Member
Mon 05 May 2014 06:24:17 PM UTC, comment #13: 

That approach seems reasonable. It needs some kind of exception handler for large arrays pasted in the Command Window.

I don't remember what MatLab or SciLab does. I'm sure I tried to swamp them inadvertently when I used them in the past.

Normally, if the array is even more than a few dozen characters, I would put it into a .m file.  I just wanted a quick answer. I was a bit surprised by the result.

Anonymous
Mon 05 May 2014 06:15:49 PM UTC, comment #12: 

Thank you for the files. I can confirm the issue with the array imMat. After clearing the history the gui is reactive again. I guess that the history viewer should truncate large arrays before displaying them like the workspace viewer does.

Torsten Lilge <ttl>
Group Member
Mon 05 May 2014 05:33:00 PM UTC, comment #11: 

I have tried cutting and pasting the array cropped to 1/2 and 1/4 the original size.

The 1/2 size bogged it down, but the 1/4 did not.

I have attached the .m file containing the array. 

I have also attached the original YAML file that I extracted the array from.

(file #31313, file #31314)

Anonymous
Mon 05 May 2014 05:02:41 PM UTC, comment #10: 

Pasting the array in either format causes it to bog down. It is not a memory issue because instantiating the array from running a .m that declares it does not bog it down.

I haven't taken the time to see if using a matrix half the size or so did the same thing.  I will try to get that done this PM.

Anonymous
Sat 03 May 2014 10:16:28 PM UTC, comment #9: 

My comment just helped to localize the problem, it isn't fixed yet. We still need detailed information on the data to fix the problem with the history viewer.

Does comment #4 mean that the problem does not occur when you paste the data without newlines in it?

Torsten Lilge <ttl>
Group Member
Fri 02 May 2014 05:18:47 PM UTC, comment #8: 

Torsten:  Thanks closing the history viewer did it.  I cleared history with the menu and the problem is cleared.  I never did find the octave_hist file.  Although, I probably could have got it with rm ~/.octave_hist, I wanted to see how big it was.

Mike Miller:
Torsten's comments fixed it.  Do you still want to play with the data?

Ralph


Anonymous
Fri 02 May 2014 04:36:19 AM UTC, comment #7: 

The fact that a restart does not help may indicate a problem with the history viewer of the gui. When you reproduce the issue could you please try to

  1. close the history viewer
  2. delete the history file (~/.octave_hist)
Torsten Lilge <ttl>
Group Member
Thu 01 May 2014 11:33:56 PM UTC, comment #6: 

It might be useful to diagnose this a bit further. So you experience a severe slowdown in the GUI after pasting a large array into the command window, correct?

Note that when typing or pasting into Octave's interpreter, newlines are interpreted as starting a new row of a matrix. So the dimensions of the resulting array in Octave were probably not what you expected. Could you try what you were originally doing and report back what the size of the variable is? Also what dimensions, type, and memory size does the 'whos' command report? In other words


x = <paste your array here>
size (x)
whos x


I wonder whether it's the size of the data, or something about the way the data is being interpreted when pasting into Octave, or the size of the scrollback window in the GUI, or the copy/paste buffer itself that is causing Octave to slow down.

Can you attach a file to this bug report (compressed if necessary) that contains the text that I could copy and paste into Octave to try to reproduce this?

Mike Miller <mtmiller>
Group Member
Thu 01 May 2014 05:08:22 PM UTC, comment #5: 

For what it is worth, the file I extracted it from is 60kb. That could put it close to 64kb for a 16 bit number

Anonymous
Thu 01 May 2014 05:04:01 PM UTC, comment #4: 

The array was 1x16485. I had cut and pasted it from a file with the text between brackets []. The numbers were separated by commas and newline '\n'.  I wasn't aware of the latter and it may have been a factor.

I have the array in a .m file with the \n removed and it works fine in the command line on the terminal.

The Synaptic package manager has an option 'Mark for complete removal.'  I marked it and removed the program.  Then, I reinstalled it (also with Synaptic).

Anonymous
Thu 01 May 2014 04:52:34 PM UTC, comment #3: 

What was the size of the array?

"But, that wouldn't explain why the re-install didn't clear it up. Unless the complete reinstall isn't complete."

Do you mean a (complete/incomplete?) reinstall of Octave does not solve the problem?


Torsten Lilge <ttl>
Group Member
Thu 01 May 2014 04:09:36 PM UTC, comment #2: 

It occurs every time.

I tried the usual stuff closing and reopening, etc.

I installed using the Debian in Synaptics for Ubuntu 14.04.  I tried a complete removal and reinstalled.
The problem was still there.

The last thing I did before the problem occurred was try pasting a long array into an equation on the command window.  So, it is possible that there was a buffer overflow of some kind that may not be being cleared.  But, that wouldn't explain why the re-install didn't clear it up.  Unless the complete reinstall isn't complete.

Anonymous
Thu 01 May 2014 03:53:44 PM UTC, comment #1: 

Thanks for the report.
When does this issue occur, every time you are using Octave? Is it reproducable? If yes, what actions  have to be performed?

Torsten Lilge <ttl>
Group Member
Thu 01 May 2014 02:32:01 PM UTC, original submission:  

Responses from command window went from instantaneous to taking five to seven seconds. Sometimes the screen dims to indicate saturated resources. Typing the line '4+3' and hitting return takes 24% to 34% of the resources.

If I write an equation in the editor and hit run and then try to open the command window, it takes about 3 seconds to open. Execution of the following took 7 seconds:

H=16;
V=9;

Diag=52;

height=Diag*V/sqrt(H^2+V^2);

In the Linux terminal, it is still instantaneous.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #31313:  ext2img.m added by None (59KiB - text/x-objcsrc)
file #31314:  imgspots.ext added by None (82KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-05-06 ttl StatusNeed Info Fixed
        Open/ClosedOpen Closed
    2014-05-05 None Attached File- Added ext2img.m, #31313
        Attached File- Added imgspots.ext, #31314
    2014-05-01 mtmiller StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code