bugGNU Octave - Bugs: bug #39646, intermediate workspace display...

 
 

bug #39646: intermediate workspace display overload when executing 'test'

Submitter:  Dan Sebald <sebald>
Submitted:  Thu 01 Aug 2013 05:53:37 PM UTC
   
 
Category:  GUI Severity:  2 - Minor
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 08 Mar 2015 02:11:33 AM UTC, comment #10: 

jwe checked in the following cset (http://hg.savannah.gnu.org/hgweb/octave/rev/793230bb81d4) which stops intermediate updating.

Rik <rik5>
Group administrator
Sat 07 Feb 2015 05:01:35 AM UTC, comment #9: 

I just added bug #44156 as a dependency.  jwe demonstrated the results of some code which turns off Variable Updating unless the user is at the top-level prompt.  This had a significant positive effect on performance.

Rik <rik5>
Group administrator
Mon 10 Feb 2014 05:56:26 AM UTC, comment #8: 

I would prefer to just not have the workspace variables refreshed.  I don't see the refresh as a real useful feature as is.  There are a probably better ways of displaying information, such as dialog boxes or strip charts or something else.  Octave may not have those things right now, but sometimes it is better to not have something than have a less than optimal implementation of a feature.

Perhaps we should instead tie the refresh of the workspace to the pause() function.  That way if someone wants to occasionally print information inside of a long batch file, they can do so with pause(0).  That's much more efficient than free-streaming the characters to the screen.  If one uses pause(0) at some rate that is more on the scale of human perception, I doubt the loss in CPU would be more than a fraction of a percent.

Dan Sebald <sebald>
Thu 06 Feb 2014 01:42:15 PM UTC, comment #7: 

can we make this a user preference, pls?
in my (slow) computer, the overhead seems waay more than 20%.

Felipe G. Nievinski <fgnievinski>
Mon 20 Jan 2014 02:12:20 PM UTC, comment #6: 

The workspace view still refreshes to show variables while scripts are running, if that's what you mean.

Mike Miller <mtmiller>
Group Member
Mon 20 Jan 2014 05:55:43 AM UTC, comment #5: 

Perhaps your Windows system library is set up to utilize the parallel operation features of the Intel chip (MMX, SIMO, or whatever many names it has been called).  The FFT is the perfect example of how to use the feature, just stack up all the butterflies and do four of them with one set of instructions.  It is really hard to say what is happening without looking at the code itself.

Has the refreshing of the screen been removed with all the ensuing GUI changes?

Dan Sebald <sebald>
Mon 20 Jan 2014 03:38:54 AM UTC, comment #4: 

This is weird, I'm still seeing very slow times for this fftfilt test loop in my Debian build, both CLI and GUI give total times of about 52-54 seconds.

However, if I test in a WinXP VM running on the same system, I get a test time of about 11.5 seconds in CLI mode and about 17 seconds in GUI mode. Closing the workspace view bumps it back down to 12.5 seconds.

Updating status to confirmed, lowering severity because closing the workspace view is an acceptable workaround, and if I remember the intended behavior was to show results in the workspace view as they are being calculated in long running scripts.

Mike Miller <mtmiller>
Group Member
Thu 08 Aug 2013 07:36:41 PM UTC, comment #3: 

Here is a test from my system (not the newest one):


GUI, workspace shown:     50 s
GUI, workspace not shown: 31 s
CLI:                      24 s


Despite of the general overhead of the GUI the activities in the workspace really slow down the calculation.

Torsten Lilge <ttl>
Group Member
Mon 05 Aug 2013 03:49:16 PM UTC, comment #2: 

You're right.  The slowdown isn't that dramatic, just a long test.  Here are the results for my system:

Without GUI:

octave:1> tic; for i=1:100; test fftfilt; endfor; toc
PASSES 10 out of 10 tests
[snip]
Elapsed time is 10.1856 seconds.


With GUI:

>> tic; for i=1:100; test fftfilt; endfor; toc
PASSES 10 out of 10 tests
[snip]
Elapsed time is 12.467 seconds.


So it is about a 20% slow down.  This is consistent with other similar time tests I've done.  So maybe the refreshing of the text isn't the problem but more generally the way in which communication works between the GUI and the core.

Nonetheless, perhaps the graphics shouldn't be refreshed until the system becomes idle at the command line, i.e., after all is complete, a breakpoint is hit, etc.

Dan Sebald <sebald>
Mon 05 Aug 2013 01:55:15 PM UTC, comment #1: 

Are you sure what you are seeing changes the time of the test? I see the same thing when running tests inside the GUI, but I don't observe any statistically significant difference in the time it takes the test to complete.

I ran the following sequence:


> tic; for i=1:100; test fftfilt; endfor; toc


In Octave with the GUI:
Elapsed time is 42.2558 seconds.

Command-line Octave:
Elapsed time is 42.0342 seconds.

Mike Miller <mtmiller>
Group Member
Thu 01 Aug 2013 05:53:37 PM UTC, original submission:  

I noticed a flash of contents of the variable space inside fftfilt when doing

test fftfilt

that goes away once the tests are done.  This really slows down the operation of "test fftfilt".

I've attached a PNG image of what the workspace looks like momentarily by running the test 100 times then capture the screen at the right moment.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by rik5
  • -email is unavailable- added by fgnievinski (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by sebald (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 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-03-08 rik5 StatusConfirmed Fixed
        Open/ClosedOpen Closed
    2015-02-07 rik5 Carbon-Copy- Added jwe
    2015-02-07 rik5 Dependencies- Depends on bugs #44156
    2014-02-06 mtmiller Dependencies- bugs #41467 is dependent
    2014-01-20 mtmiller Severity3 - Normal 2 - Minor
        StatusWorks For Me Confirmed
    2013-08-05 mtmiller Item GroupNone Performance
        StatusNone Works For Me
    2013-08-01 sebald Attached File- Added Screenshot-Octave-workspace_overload.png, #28737

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code